Remote for life July 22, 2017

The last time I went to an office was in 2007.

I remember never quite feeling at ease. Wanting to work but feeling like there was a pressure to stay for the full eight hours. Not feeling like I could go take a break to clear my mind. Subordination.

Ten years later and I've invested in working from home.

I've built myself a lovely minimalist workstation where I'm able to be productive without distractions. I work in my sweatpants and make my own lunches. I'm simultaneously productive and happy and free. This is the lifestyle that works for me.

I know I might be missing out on career opportunities because of my stubbornness to work from home, but in my view they're not worth the commutes and the feeling of entrapment.

There was an article in the New York Times yesterday about people with commutes more than 2 hours. If you work an 8-hour day and commute 4 hours per day to get there and back, that's a 33% pay cut.

My trip to Portland reminded me how city commuting can be stressful. The busyness and the sense we all have to be somewhere fast. From my perspective, we ought to spend our time figuring out how not to do that anymore.

That's why I've built my life around working remotely. And while I might turn down opportunities to grow, I know I'm in control of my own time.

The Portland I used to know July 18, 2017

I went to Portland this past weekend to attend Edward Tufte's excellent Presenting Data and Information course.

Having lived there for the better part of a decade, I've always thought of Portland as my adulthood home. A place to which I'd return someday. A place bookmarked in time.

But now I'm not so sure. The experience I had in Portland this time left my befuddled: Had Portland changed so dramatically in the three years I'd been gone, or did my own values change?

My friends there say it's probably a bit of both. I remember a Portland where ordinary people could afford to open small businesses. Now it seems as though all of those lovely local businesses are closing. I'm not opposed to change and certainly don't think preservation legislation is the answer, but it's a difficult and depressing pill to swallow.

And can we talk about the cultural shift? I don't mean to stereotype, but I'm about to. When did Portland go from a place where the punks and weirdos thrive to a place where it seems as though people go to great lengths to manicure their appearance to the point of absurdity? Was Portland always the epicenter of douchey-cool and I've just grown out of it? Or has it reached its tipping point?

I still love the Portland cityscape and don't bemoan out-of-towners who dream of moving there. One of the unique draws of city life is being surrounded by people different from you. But Portland's recent homogenization represents a shift away from that diversity. I'm not talking about racial diversity or even ethnic diversity. I mean diversity of ideas. A place where both artists and businesspeople can thrive. That's the Portland I left. And now I'm not so sure I'll go back.

Buffers July 11, 2017

Life is peaceful when there are buffers.

The time between the present moment and your next obligation is a buffer. The money in your bank account that protects you from insolvency is a buffer. Food in the pantry. The space between your neighbor's house and your own.

As I've grown older, I've noticed I want wider buffers. I'm less willing to allow them to shrink to their size ten years ago. Busyness. Brokeness. Empty pantries and tiny apartments.

Part of me misses that wild abandon. But when I sleep at night knowing there's a cushion between me and the world, I smile.

How to name and organize your React components July 10, 2017

When I first began building complex React applications, I struggled to determine the best way to name and organize my components within my codebase. Having come from the Rails school of convention over configuration, I was perplexed to find that most modern JavaScript apps rely heavily on custom configuration and don't adhere to any sort of community-driven conventional norms. That's changing slowly with the advent of toolkits like create-react-app, but even its conventions go right out the window as soon as you npm eject.

After a couple years of learning and mistakes, there are a few guidelines I use when organizing my React components so my code is more readable, understandable, and succinct.

Compose your components into smaller subcomponents

While it's tempting to just keep adding bits and pieces to your component's render method, this can grow to the point where it becomes difficult for new eyes to discern your intentions. Imagine a render method like this:

render() {
  return (
    <div className="todo-list">
      <div className="todo-list__items">
        { => (
          <div className="todo-item">

Instead of rendering todo items within the root component's render method, create a new component:

const TodoItem = props => (
  <div className="todo-item">

Then, call it in our root component's render method:

render() {
  return (
    <div className="todo-list">
      <div className="todo-list__items">
        { => (
          <TodoItem item={item} />

It's a subtle change, but making these sorts of changes proactively can keep your components readable. And becuase React only re-renders those components that change, extracting smaller components can improve your application's performance.

Extract iterators into class methods or new components

Extracting a subcomponent is a good first step. But we can go one step further by extracting the map iterator call into its own method in the root component. This improves the readability of the render method:

render() {
  return (
    <div className="todo-list">
      <div className="todo-list__items">

renderItems() {
  return => (
    <TodoItem item={item} />

Now when we scan the render method, we see a more succinct summary of its contents!

Only use ES6-style class components where state is needed

Notice in my previous example that I've opted to use const to define the TodoItem component. This is because, in its current incarnation, the TodoItem component is stateless.

In React, stateless components are merely functions that return a React-wrapped DOM element. Unlike using the ES6 class keyword or the now-antiquated React.createClass method, stateless components cannot hold their own component state in a this.state object.

The reason this syntax is favorable is because it encourages authoring code in a functional style. Let's expand our TodoItem component to include a "Delete" button:

const TodoItem = props => (
  <div className="todo-item">
    <div className="todo-item__title">

    <button onClick={props.onDelete}>

Here we've enclosed the title in a new container div, and then added a <button> tag with an onClick handler set to a hypothetical onDelete thunk handler that we would pass through from the parent component.

Just like in our iterator extraction example above, there's opportunity to make this component more readable. However, because this component is stateless we can use a more functional style:

const Title = props => (
  <div className="todo-item__title">

const DeleteButton = props => (
  <button onClick={props.onDelete}>

const TodoItem = props => (
  <div className="todo-item">
    <Title value={props.item.title} /> <DeleteButton
    <DeleteButton onClick={props.onDelete} />

Our goal in doing these extractions is to reduce fatigue when scanning your components' code. New developers who visit this code for the first time will be greeted with components whose markup is only a few lines, making it much easier to parse and understand than if they were tens or hundreds of lines.

Keeping this habit early on will mean your codebase can grow and remain understandable to newcomers.

Organize composed components into subdirectories

So far, we've built the following components:

  • TodoList
  • TodoItem
  • Title
  • DeleteButton

As our codebase grows, the way we physically organize our code on disk is going to become more critical. I've experimented with a couple methodologies.

The first is to create a directory called components, dump all your components in there, and call it a day. This is fine for projects with fewer than 20 or so components, but it becomes cumbersome as the number of components grows.

Instead, I've settled on creating subdirectories for certain root-level components. In our example, we could envision the following directory structure:


Organizing our components in this way has the following benefits:

  • Components only ever reference other components within their own subdirectory.
  • We can name components based on their context. For instance, instead of naming our item component TodoItem, we can call it Item. This reduces unnecessary verbosity.
  • Our components become portable. By encapsulating their hierarchy within a single directory, we can reuse the component in other codebases easily.

That feeling when you want to give up July 10, 2017

Marketing yourself sure is an anxious chore. I'm plenty qualified for all sorts of full-time jobs, but I'm resolute against taking one since I know I work best when I'm free.

What does freedom mean to me?

Freedom means the ability to wake up when my body tells me instead of when an alarm sounds its siren. It means I can take some time between clients to ride my bicycle around town casually without worrying that I need to return to the office. It means I'm not burdened by day-to-day inter-office politics. That I can provide immense value without being physically present.

But it's tough out there. Not in the economic sense; there's probably plenty of work to be done. But marketing yourself as a consultant is no easy task. Most consultants probably wouldn't admit such a thing on their website for fear of being perceived as a failure or a fake.

I'm not afraid of that because I know my value, but I am afraid of failure. I'm afraid I'll soon be applying for jobs and working 40 hours per week and giving up on this whole consulting thing for good. Which is humorous in its own way given the fact I'm nowhere near failing. But that's how fear works, isn't it?

Limiting beliefs and the tech industry July 9, 2017

Limiting beliefs are beliefs we hold which constrain us in some way. We define ourselves by what we do or don't do, what we can or cannot do, what we are and what we aren't.

The tech industry, with its continuous cycle of innovation, cutthroat competition, and social darwninist hierarchy, can foster some pretty sinister limiting beliefs. I struggle with them regularly and I'm sure you do too.

I'm too old. There's plenty of chatter about ageism in the tech community. As someone who's turning 32 this year, I'm fearful of it, in spite of not having experienced it. I do wonder though, whether ageism is a bogeyman insecurity that can be overcome in the minds of those affected, rather than a form of systemic oppression. It's tempting to give up on that new startup or to believe we're unable to grasp new technologies on account of our age. But the market doesn't care how old we are, truthfully.

The market is too saturated. I'm running up against this resistance right now myself. Building a consulting business is no easy task. There is plenty of advice of how best to proceed when building a consulting business, and I've learned over the past few months that it's easy to get sucked into their vortex and forget to do the work. While some of the advice is prudent to follow, most of them are just selling shovels to the miners. I'm learning that the best way to build a business is to build the business. The market doesn't care how many players are in the game. It's just a matter of standing out among them.

All the good ideas are already taken. This one is fascinating to me, but I'm still succeptible to it. Imagine someone saying this in the days before the Internet. Lawyers didn't decide not to start a law firm because there were already lawyers in the world. Dentists didn't say "Well, there are already people fixing teeth. I guess that dream is off the table." Why are we so caught up in the notion that our idea need to be original? Competitors are a sign there are people willing to pay for what we offer. It's just a matter of providing more value than they do.

I'm writing this as a gentle reminder to myself: There's abundant opportunity for thoughtful and innovative people. It's just a matter of training our minds to open.

Why aren't more companies hiring independent consultants? July 8, 2017

I'm noticing a trend as I'm bootstrapping my consulting business. There are plenty of awesome software development gigs, but most of them are full-time positions.

I have nothing against full-time positions; they're great for people who enjoy capturing a regular paycheck each month and don't like the sales process. But I'm not sure I understand how hiring full-time staff benefits the employer, especially in terms of cost benefit relative to hiring results-oriented consultants to complete the same work.

Employees are paid for their time. No matter the enriching culture you provide them internally, they have little incentive to be efficient aside from the possibility they'll lose their job. Most employees do want the best for their company, but their principal concern is the livelihood of their families and their ability to live life on their own terms. Paying an employee's salary for a year does not translate into results for the business. I've spent months as an employee working on projects which never made the company a dime because they were ill-conceived from the start. I got paid and the company got nothing.

Consultants charge for the outcomes they produce. If you need a new user interface for your web application, I'm going to spend a fair amount of time asking you why you need it. I'm going to dig deep into how such a move could improve your business fundamentals. I'm going to ask you difficult questions that have more to do with sales, marketing, and users than technology, infrastructure, or design.

When I send you an invoice, I'm going to tell you exactly the results you paid for. If you're not satisfied, you'll get your money back.

Feeling pressure to keep your team members employed because you know they rely on you for paying their rent? Hire a consultant and you won't have that problem. I'm happy when you don't need me anymore. Hopefully I worked myself out of a job and you can spend the money you would have allocated to my salary on marketing to more users or innovating in other ways.

There's a stigma abound that independent consultants are hawks looking to scoop up a payday without providing real value in return. I want to debunk that myth for good. Consultants are seasoned professionals who realize they don't thrive in the employer-employee model. We want nothing more than for you to succeed and to help you find the best possible path to get there. Our business is not one of billing hours, but of optimizing costs. We charge fees not based upon the time we spend, but based upon the value we provide.

A notificationless life July 4, 2017

I'm an anxious person.

Wait, strike that. I'm striving not to carelessly apply labels. I sometimes suffer from anxiety. There. That's better.

I sometimes suffer from anxiety. Having spent the majority of my waking adult life in front of a screen, I'm no stranger to the anxiety-inducing nature of life online in 2017. The average computer or smartphone user has hundreds of apps vying for their attention, each hoping to take a slice.

It didn't used to be this way. Before 2009 and the introduction of Apple's Push Notification Service, your iPhone left you alone except for when you received a phone call or a text message. Those were simpler times.

Now, if we don't do something about it, we're subject to a near-constant buzzing and chirping. Emails. Text messages. Tweets. Likes. It doesn't stop. As a technologist, I feel almost apologetic for the culture of distraction that is now our everyday reality.

That's why I want to do you a favor. I'm going to make a suggestion that hopefully will change your life for the better. Ready?

Turn off all your notifications.

That's right. Turn them all off. Even your text messages. Maybe leave your phone call notifications on so people can reach you in case of an emergency. But you haven't experienced the serenity the people of the twentieth century took for granted until you turn off all your smartphone notifications.

Afraid you'll miss something? You won't. If something is important enough, someone will call you.

Consultant vs. Freelancer July 4, 2017

Consultant. The word conjures up thoughts of business attire, meetings, and an expensive invoice. When you're going to hire a developer, you usually don't seek out a consultant. In fact, you might steer clear of them for fear that they're only out to line their pockets. What you're looking for is a freelancer. Someone you can trust. Right?

It's difficult to discern the difference between the two, so I want to explore what each term means and how to gage whether the person you're hiring should be deemed a consultant or a freelancer.

The biggest distinction between a freelancer and a consultant is that a freelancer thinks in terms of deliverables, while a consultant thinks in terms of outcomes.

Imagine you're losing sales to your competitors and you attribute this loss in sales to your competitors' superior online sales experience. You want to hire a developer to build an online store that can rival your competitors.

When hiring a developer who bills themselves as a freelancer or contractor, it's likely they'll focus more on the deliverables. They'll take orders from you and you'll (hopefully) end up with the online experience you envisioned.

But what if that online experience doesn't result in the outcomes you expected? What if it has a net negative impact on your sales?

It's not your developer's fault, necessarily. They built what you asked for, focusing on what to build. But their interest and focus is on deliverables—the website, the technology, the means. Yours is on outcomes—the traffic, the sales, the customer satisfaction.

But what if your developer understood your desired outcomes? And what if instead of billing you merely for the time it took them to produce deliverables which may or may not achieve those outcomes, they billed you for actually achieving the outcomes?

That's the essence of hiring a consultant. You're not paying for a web application; you're paying for the results that come from that web application. A consultant is a partner. Their interest is your interest. They guarantee outcomes that they believe they can deliver, instead of billing you arbitrarily for their time which may or may not produce the desired results. They seek to intimately understand your business and how it can be improved through technology. And because they're billing you for the results they achieve, they're not going to sell you technology you don't need to achieve them.

How is prototyping different? June 5, 2017

Usually interactive projects involve one or all of the following creative talent:

  • User experience (UX) designer
  • Visual designer
  • Front end developer
  • Back end developer
  • Quality assurance engineer

A traditional project lifecycle looks something like this:

  1. The user experience designer expresses user flows and wireframes which represent the final product. After your approval...
  2. The visual designer processes the wireframes into mockups which capture the client's desired visual aesthetic ("look and feel"). After your approval...
  3. The front-end developer begins building the mockups into HTML, CSS, and JavaScript, which drive the user's experience in the browser. They'll also inform the back end developer of what API will be required. After your approval...
  4. The back-end developer builds the API while the front-end developer integrates.
  5. If you're lucky, a QA engineer tries frantically to break things and reports what they find to the developers for fixing.

And if you're really lucky you'll have nothing but praises to sing about the your product and everyone can go home early.

Except that never happens.

What really happens is that you notice things. Things you didn't notice when all you were working from were some black-and-white sketches. You realize a button's text is confusing, so you ask if it can be changed. Your supervisor informs you that the product needs to work differently.

If only you could have shown your supervisor sooner.

If only you could have seen your product in its early stages to collaborate on its success, instead of leaving it to the mercy of an agency.

That's the problem prototyping solves. Prototyping is when you build a product iteratively, collaboratively, and with as little upfront design as possible.

It puts experimentation above specification, and outcomes above delivery. It implores developers to become product- and design-focused instead of just playing an adult game of paint-by-numbers.

Your average developer builds software according to a design specification.

Developers who prototype design software to achieve outcomes through experimentation.

A new paradigm

As programming tools have increased in capability, developer productivity has increased with it. It's now not unfathomable that a solo developer execute both the design and implementation of a small- to medium-sized digital product.

Composable user interface libraries like React mean we rely less and less upon visual designers to inform the first versions of our products, because it's trivial to iterate on visual aesthetics in the midst of a product build.

And technologies like hot reloading of stylesheets mean that a developer fluent in CSS can rapidly design a gorgeous user interface without ever consulting a visual designer.

Paradigm shifts like this one have occurred throughout the course of software development history. Agile development killed the idea that you could build software successfully with rigid upfront specification, but its methodology speaks very little about user experience and what role developers play in shaping it.

I believe we're now going through another transformation: The realization that developers, if up to the task, can play a unique role in driving the user experience conversation. And that role can be so profound that it changes the entire process of product development.

Now, I don't want to make any wild claims that visual designers are unnecessary or that all developers should start focusing on user experience. After all, we need specialists in all sorts of disciplines, and big projects will always require the leadership of a visual designer to create cohesion and establish identity. But I do think that as product managers, entrepreneurs, and anyone who buys professional software services realize the potential in granting product leadership to their developers, we're going to see a shift in methodology.

And too, as developers begin to recognize the value they can bring to a product by becoming more involved in the user's perception, experience, and value, they too will embrace this subtle but powerful change.

The power of simultaneity

A non-technical user experience designer can offer only so much in terms of real value to end users. They can demonstrate a concept, but not execute it for analysis.

A non-technical visual designer can produce a new identity for an interface, but relies upon the whims of a paint-by-numbers developer to bring that concept to customers in the product.

A design-focused, user-focused developer can execute all of this simultaneously. They're able to conceptualize a visual identity, produce a working prototype of an interface concept, and give it to real end users to test their hypothesis.

By putting your developers in the design seat, you reduce the communication feedback loop that inevitably occurs between designers and developers. This new autonomy produces design decisions which both serve the user and consider technical challenges.