It's in every engineering leader's job description: "hold people accountable."

Accountability is a funny thing to use as a critical skill for a high level leader, because in many ways the core of what this is saying is "do the job."

Let's talk about the message under the message here a bit; what are these companies really looking for when they say you need to hold people accountable?

Let's imagine a scenario to play this out.

We have an imaginary EM Marcus. Marcus is responsible for three teams who are delivering work on critical projects.

Each team has a few engineers and a product manager. Marcus is responsible for reporting on the team's progress.

Teams A and B are smooth sailing. Team A is brand new with onboarding engineers, so they don't have a significant project on their plates other than getting up to speed. Team B is well staffed and their project is running along slightly ahead of schedule.

Team C, though, is struggling. They are under-resourced, and their project is running behind by a couple weeks.

So, where and how does accountability show up in this picture? I'm going to present three different forms of accountability and how it applies to the situation.



As organizations heads into a future where cross-cutting projects are the norm, they face an intuitive question: should we align our teams around projects, or is there a better way?

The answer isn’t clear cut, but let’s dig in to the pros and cons, and how each of these models would look.

First, we’ll explore how project and domain team paradigms would work.

## Project Teams

Teams will be assembled to tackle projects for their duration. When projects are large, multiple teams may be assembled; those teams may be assembled based partially on rough domain / service boundaries, or based on tech stack horizontal (backend, frontend, etc).

![](../assets/post-images/project-teams.png)

As the diagram illustrates, teams will be dynamic and reallocated based on project demand. No formal team structure would map to service work; service work would be slotted in on an as-needed basis.

There are two possible reporting structures in this world.

**Project Team Structure, Option 1: Dotted line reporting (QB + people-manager)**

Engineers would have a dotted line reporting structure. Their primary people manager would manage individuals across multiple projects. Engineering managers may also be responsible for “QB”-ing an initiative, assembling the teams around a project and organizing the resources and timeline, etc. This QB role may instead be held by director-level managers. However, engineering managers may not be as involved in technical planning in this paradigm, as their reports are spread across many projects.

EMs might be aligned to one or more services, and engineers would still operate as codeowners over services or areas of code. The EMs would be in the know about their individual engineers’s projects, but are not necessarily leading those projects. A given EM may be a QB for a project where only one or two of their reports are working on that project. It is unlikely that an EM is a QB for a project where none of their reports are actively involved.

Performance management in this world can be a challenge; a given engineer’s people-manager EM would request feedback from the QB and other collaborators for that engineer’s work over some period of time, but direct observation would be a less common opportunity in this paradigm.

**Project Team Structure, Option 2: Agency Teams**

In this structure, teams will remain with the same manager, and the whole unit moves between projects. This is largely reflective of an “agency” model. Managers would not be tied to any domain or service necessarily, but teams would work quarter over quarter together on a variety of projects.

The concept of codeowners gets stretched in this paradigm, as a given codeowner may not be touching their “homebase” code for a long period of time. Thus this paradigm does not optimize for code ownership.

If there are multiple teams working on the same project, their may still be a project QB under this format.

Generally, teams would work in areas they are familiar with, but this is not a strict rule as much as it is a heuristic in this structure. Teams may be organized into multi-functional units (i.e. crossing skill boundaries), or could be grouped by skill (i.e. “backend team”).

**Service work and KTLO in a project-oriented environment**

Service work would be done as a secondary priority in this format. Because teams are assembled around projects, the incentive to focus on project work is implicitly higher than the priority of ongoing service work. Additionally, the resources available for a given service would be dependent on the project load share on the service’s codeowners. There is one exception to this rule: when a given project is entirely within the context of a single service (or close), the team, project, manager, and service all remain aligned.

## Domain Oriented Teams

In contrast to project teams, which are fully (or almost fully) focused on a single project crossing multiple services, a domain team would be responsible for projects as they impact a given domain.

Not all projects cross domain boundaries; it is also very rare that a project will cross _all_ domains at any company of reasonable size.

![](../assets/post-images/domain-teams.png)

In this paradigm, engineers allocate a percentage of their time to different types of work. The organization lays out the projects and the relative priority between them, and teams work to determine what execution ordering and structure would make sense based on dependencies, priority, and resource constraints.

As a general rule, assuming all things being equal, highest priority projects receive first attention. However, in reality, prioritization is not always as simple as “this project is top priority.” Some examples of how it gets complicated:

- Some work, though not necessarily urgent, is a blocker for other work that will _become_ urgent.
    
- Some work is unpredictable in its smallest form (though reasonably predictable as a collective whole) and critical for the company to survive (KTLO)
    
- A given set of work may be difficult or impossible to parallelize, thus two teams may simultaneously be working on things of different priority levels
    

Domain oriented teams are organized in an effort to retain some level of domain expertise across the critical areas of the company. However, sometimes in a domain oriented team, the cross-team coordination required to finish a given initiative quickly can be a challenge. This is when Tiger Teams might be useful.

Tiger teams provide an avenue to assemble a temporary project-oriented team to accomplish a given set of work. This temporary team looks very much like the previous paradigm - a project QB is leading the team through dotted lines, and each member has a people manager that they report to directly.

Tiger Teams should only be assembled for a clear and discrete scope of work, and should not become the “norm” in this paradigm, as this transfers the burden of the KTLO work onto fewer members of the team in addition to other ongoing cross-coordinated project work. If every project is “critical” enough to assemble tiger teams, then it would be better to align to a project-oriented paradigm all together.

As depicted in the diagram, there are also overlaps of collaboration topology that should be made clear when two or more teams are working on the same project.

When two teams are planned to work on a project, it is useful to describe how those teams will interact during that project’s lifecycle. Is one providing a service to another? Are they collaborating on building a common codebase? Is one team facilitating another through mentorship or other kinds of help (knowledge transfer, for example)?

# What considerations should we make when picking between these paradigms?

Generally speaking, look at your intentions for the long run. If you are moving toward a service oriented architecture, the implications are very different than if you want to run a mono-repo or even a monolith.

Perhaps you are preparing for an exit - in this case, your focus likely will be on certain projects rather than creating long-lasting domain knowledge and org design.

Maybe your product is pivoting quickly, and you are building many POCs. This is another situation where a project orientation makes more sense.

Overall, the prevailing consideration is to understand what you are *investing* in. With a domain orientation, you are investing not only in the current ongoing new priorities, but in maintaining the existing surfaces and complexity you've developed in the past.

If you're in early startup territory, you may not even *know* what your domains *are.* That doesn't mean you can't start doing some kind of domain modeling, but at that stage your org design is probably limited more by resources and lack of scale than anything else; project orientations actually serve to extend domain knowledge out of individual silos in this case.

In *most* cases, however, the paradigm of domain oriented organizational design is a reasonable default.

Finally, it's reasonable to consider the ownership model your organization currently has. In most organizations, domains emerge either within a singular (or many similar) contexts that combine multiple domain concerns into a single codebase. Ownership is mostly dependent on the conceptual domain, but is not clearly delineated in the actual code.

![](../assets/post-images/provider-owned.png)

In a service architecture that aligns ownership with services, the calls tend to look more separated, and the caller owns the call locations themselves.
![](../assets/post-images/caller-owned.png)

In this case, the caller would be responsible for whatever integrations they have with other services. This model fits generally better with domain oriented teams than with project teams.
# What type of team approach makes the most sense in a service-oriented architecture?

> Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
> 
> —  Melvin E. Conway, How Do Committees Invent?

As a broad-strokes assertion, most service-oriented architectures lend well to domain-oriented teams, in part because of Conway’s law. If the organization of people matches the system they tend to create, our organizational structure matching our SOA is a reasonable starting place.

And, this may also help us describe why project orientation is tempting in the first place; with our current monolithic structure, it’s a reasonable expectation that you might touch _any_ part of the codebase, so why would we draw boundaries that don’t exist in our system? (This might be a sort of a reverse version of Conway’s law, that we might design our communication structures in a way that fits the system.) And if we had plans to double down on keeping the monolith, this recommendation would be a fairly clear frontrunner.

Let’s explore the pro’s and cons of each approach in the context of service oriented architecture.

## Project Oriented Teams: Pros + Cons

|**Pros**|**Cons**|
|---|---|
|Efficiency of focus|KTLO becomes far less structured without supplemental organizational planning|
|Staffing based on skillset becomes only a matter of prioritization|Domain expertise may falter as projects jump across domains|
|Consultant capacity is easier to scale-in / out in project oriented work|“Projects” become products; teams that work on a project may disband (depending on squad cohesion strategy). The product then does not have clear ownership, and the distributed ownership problems of the monolith are perpetuated|
|Encourages individual responsibility|Codeowner strategy becomes thin; easy for code to accidentally go unowned or abandoned, hidden risks when the only codeowners of a given area depart the company|
|Provides variety to engineers who may tire of working on the same domain service for an extended period of time|Can result in many different paradigms / technical approaches that compete with each other. This can be messy and inconsistent, creating a “stack of projects” rather than a coordinated set of services, resulting in more information silos|
||Ownership set at project boundaries would passively encourage the whole tech stack to be homogenous.|

## Service Oriented Teams: Pros + Cons

| **Pros**                                                                                                                                                                                                                                                                                                                                         | **Cons**                                                                                                                                            |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Long term stability of domain services                                                                                                                                                                                                                                                                                                           | Split focus situations when projects don’t perfectly line up with a full team’s capacity                                                            |
| Identification of outlier concerns with new implementations; as projects are executed, teams ask “how should we integrate this new concern with our domain”                                                                                                                                                                                      | Success for the team may be hard to define, as the business cares less about individual team deliveries and more about project deliveries           |
| More traditional approach to enable SOA. Services can differ from each other, and this differentiation may align with squad skillsets. For example, a given service may be written in a completely different tech stack than another. Having squad ownership lines drawn at service boundaries rather than project boundaries allows for this.   | Onboarding into a domain takes longer than onboarding on to a project, as the history of decisions for the service lay across many past “projects.” |
| Business effort should be allocated based on business interest; domain oriented teams allow organizations to directly invest in ongoing work on areas of the business that are useful, and reduce in areas that are not. This is a forcing function to reduce complexity in unimportant domains / cost centers, and invest in important domains. | Domains are not always “team-sized” - thus a given domain may require multiple teams in tandem to cover the breadth of the problem.                 |

# So what should we do?

No matter which direction your organization goes, the answer to this question is complex and opinionated, and might not be as clear cut as this document proposes. However, based on the assertion that our organization will move towards a service-oriented model, and we want to create a sustainable architecture and teams that can support that architecture in the long run, **this document proposes a domain-based model of ownership and planning with a percentage allocation to tiger teams.** The percentage should be something decided on an ongoing basis, with an ideal maximum threshold set around 15% of resources dedicated to tiger teams. That would translate to 3 engineers per four squads, based on 5-person squad size. Anything greater than this begins to erode the sustainability and predictability of team structures.

Project or Domain Teams?

**Correct focus outpaces brute efforts and long hours.** The perennial problem of productivity is almost never solved with "more." It's easy but incorrect to imagine that our productivity is based solely on our ability to drive output. More correctly, it is based on our ability to develop laser focus on the right things. Thus the vast majority of my management style is not focused on driving people to "work harder" (which almost always roughly translates to "more hours"). It is instead pointed at generating the clearest possible focus. The marginal gains in productivity seen by driving more hours are almost never worth the damage done to peoples' mindset and feeling of buy-in. If your team can't be successful within normal working hours, one of a few things must be true, in order of most to least likely.

- You are not focusing on the right things
- You are not planning effectively
- You have a talent or capability issue
- You have a motivation / willingness issue

How can it be that these are in this order? Based on pure statistics and reasoning we can arrive at this conclusion.

Focusing means finding the right problems to solve; this could be a problem that goes as high as the fundamental market positioning of your company, or as low as a ticket prioritization issue.

Focus Beats Effort

I've decided to publish my "Work With Me" doc in a place I own as I generally believe my working style largely remains the same across job roles. That said, this "work with me" doc is subject to change as my role shifts.

In general, my roles tend to be in some kind of engineering leadership position, and usually I have people that report to me. So, this document will be biased toward that perspective.

### Leadership Style
I believe that leadership starts with clarity. Clarity in goals, motivation, expectations, and situation. If there is a lack of clarity, the primary job of a great leader is to find or create that clarity. Clear is kind.

**What values do I represent as a leader?**
- **Trust** - I believe trust is the foundation of all positive working relationships. By default, I "trust but verify." When we lose trust, it becomes the top priority to resolve that.
- **Communication** - the conduit of our work together is communication. This is the medium of clarity; if our communication is breaking down, all of our work will follow. Good communication is necessary to maintain trust.
- **Responsibility** - The hallmark of a good leader is the ability to accept responsibility in any scenario. Responsibility does not mean "accepting the blame for someone else's mistake" - it is forward-facing. Responsibility in almost all circumstances means stepping into a situation and owning the next step.
- **Proof over gut** - great leaders don't just trust their gut. They take it into account, along with a bunch of other checks and balances that are observations of reality. Going with your gut is usually a tradeoff of efficiency. For big decisions, or for repeated processes, the more we can integrate our intuition with observed measurements, the more accurate and informed our decisions can be.
- **Action and Grit** - In every circumstance, I imagine I am in the pilot seat. I'm not along for the ride; I make things happen, I am a part of the solution, and life doesn't just happen to me.
	- Note that when you see a lack of this, it is often because of fear. Inaction comes often when psychological safety is lacking, because people are afraid that failure in their actions might result in negative outcomes for them. This is a disabling state that returns to the governing factor: trust.
- **Humility** - Humility means being honest about the reality of our own limitations. This is at an individual level as well as a team level. The best leaders I've worked with were the first to say "I don't know", and the first to admit "I screwed up." In every case, humility worked in their favor and did not undermine their leadership; I aspire to this level of transparency.
- **Confronting Reality** - Much of our jobs as managers is to find and manage the *reality* of a given situation. (Pro tip - This is really just an extension of humility.)
	- For example, we have a major delivery due at the end of the month, but based on our performance data we are trending to deliver end of next month, and we just lost one engineer to attrition. The reality of this situation is that there is a very slim chance we will deliver on time. Trying to get around this by using poor management tactics or rhetoric is the hallmark of an immature leadership culture.
	- The best working environments are the ones where we can observe truth together and decide what to do about it - not ones where we try to spin the situation to look better for us.

**What do I expect from other managers?**
- **High integrity** - say what you mean, do what you say.
- **Focus on what you can do** - It's often easy to see what's wrong. It's harder to decide what to do about it. But that's what a great manager does!
- **Clarity** - if you need something, ask for it! If you are concerned about something, make it known.
- **Human spirit.** - we don't have to approach most problems like we are saving the world. Yes, it's important to focus and do good work together, but sometimes the best thing we can do is laugh together. Managers set the tone for the workplace, and if all people see is seriousness, challenge, demand, and cold calculation, they will leave their own humanity at home when they come to work.
- **When data is available, us it.** - Ignoring data is like putting your head in the sand. Backing up your decisions with data is a part of what it means to confront hard truths.

**What do I expect from engineers?**
- **Do the right thing.** Often this means doing what you feel is the best option in the scenario; not cutting corners. However, sometimes the "right thing" can be ambiguous or dependent on the situation, which is when we talk about it as a team. Doing the right thing also extends to our moral and ethical considerations as a team.
- **Make your work visible.** Work that isn't documented is hard to track. The organization and you benefit from making your work visible, both because it is shown to help with productivity and clarity, and because it provides a history of contribution.
	- Note: this isn't *just* about tracking tickets in Jira (though that's part of this) - it's also about making clear what your decisions are, and providing a paper trail for the soft parts of your work that don't fit in a ticket.
- **Learning mode is always-on.** The industry changes quickly. What you need to know to be successful is always evolving. It is critical for engineers to pick up new hard and soft skills to grow their careers.
- **Focus on impact.** We don't bike shed over unimportant details. When we disagree, we focus on what it will take to move forward, not on bolstering arguments further. "Impact" means different things in different circumstances; part of this skill is learning how to identify *what* impact matters in a given situation.
- **Adaptability.** Every organization I've been a part of has undergone some kind of major change. Being able to ride through the changes is an important part of what it means to be a successful engineer.
	- Note that I'm *not* telling you you have to agree with every change; rather, that organizations will always be changing, and holding on to previous notions of an org produces friction that may not be useful to you, and instead may hinder your growth in that org.
- **Commit to your team.** We win and lose together. We build our agreements, we stick to commitments, we support each other. We are not individuals working near each other - we work *together.*
- **Take responsibility for aligning your work with your career goals.** Your biggest opportunities will come because you are ready to grab them. I am a good advocate for your success, but ultimately you are your *greatest* advocate.

I bring my [personal values](https://jonathancutrell.com/values) into my work; you can expect those values to drive my own behaviors. Not all of them translate in every context, which is why I'm keeping them separated for the sake of this document, but the discussion below may have some significant overlap with those values.

**Overall, you can expect me to be people-first in my approach.** This is an easy thing to say (and lots of people claim some version of this), but in practice what does this mean?

**Humans are not machines.** We are organic, head, heart, and soul. Our goals of working together are ultimately subordinate to our individual humanity, our personal search for meaning, our own full experience. Our emotions - fear, excitement, joy, loss, anticipation... all of these are more powerful than any OKR or Jira board can capture. This means that predictions about humans are less reliable than predictions about machines. Over the course of many humans, predictions become more reliable, but individual outliers are not only possible - they are fundamental to what it means to be human.


Work With Me - Values and Philosophy


On the 4th of July this year, I almost died. I think the most important thing for you to know, out of the gate, is that it wasn't fireworks. The second most important thing for you to know is that I'm fine now, physically speaking.

### How it happened
You may or may not already know that I am a powerlifter. Well, I usually am a powerlifter.

Right now, I'm injured, so my lifting is limited. (Pre-existing condition to the almost-dying incident.)

To say I'm a powerlifter is to say I'm a programmer - I haven't written much code as a manager. I start to feel some impostor syndrome after a while; is the cure to remind yourself you can do the thing, or to become capable at doing something else? Can I be comfortable with saying "I have done some programming" or "I have done some powerlifting"?

Anyway, I was adjusting my power rack. It was an 8-post rack, I decided it was time to change it to a 6-post rack. My goal was to remove the front two posts, take the connections from those and put them between the back two and second pair of posts. (These details are mostly for my memory and are not particularly germane to the story.)

I had successfully removed the front two posts and extenders, and had disconnected the back to posts. So now we have a two-post and four-post structure. The two-post structure also has a lat-tower attached to the back. (The important thing there is it had "feet" on the back side that I assumed made the whole thing stable.)

I was up on the second step of a two-step stepstool when I felt the lat-tower two-post structure tip onto my shoulder.

Now, as the astute reader will note, if I pushed against this tower, the step stool would buckle under me. If I didn't push against it, the situation would eventually resolve itself anyway. At first I was able to hold it up, to try to figure out what to do.

I realized the gravity of the situation... no pun intended.

In no uncertain terms, I screamed for my life in the most guttural fashion. I screamed for Lauren, my wife, to come help me. She arrived to the room moments later, yelling at me asking for instructions. A handful of choice words later, she was pushing on the two-post structure, but considering the structure held a combined weight of something around the one-ton mark, she was unable to push it.

It's a bit blurry, but eventually there was no choice but to go _with_ the rack to the ground.

### Part Two: Better Than The Lottery
I laid on the ground stunned at first. The fall was oddly slow - I guess because it wasn't like something falling straight down off of a shelf. I was convinced that my legs would both be broken at least, and much more grisly at worst.

My wife still screamed at me, "are you okay!?"

I have to admit, at that moment, I did not know if I was okay.

Something had pinned my leg to the ground, but I was able to get out from under it. And, in a moment of absolute fortune, I stood up. Structurally, my bones seemed fine. I had some scrapes, but I was ok.

My whole family and I spent the next few minutes recovering emotionally from what happened. My children, 3 and 6 years old, hugged me before saying anything.

I surveyed what felt like the aftermath of a car accident in my interior gym, and realized there were about a billion ways this could have gone wrong.

I often think about alternative timelines and the "infinite universe" theory that inspired the movie Everything Everywhere All At Once. The tldr; - anything that could possibly happen is happening and has happened, because there is no known boundary on the universe... thus, all possible arrangements of matter are occurring in *some cosmic reality.*

I'm convinced that in almost every arrangement that was identical up to moments before that rack fell, the constituent parts of matter that make up my alter-egos are now in a grave.

That is, I did better than winning the lottery.

Winning the lottery is only applicable if you are alive. I guess if someone wins the lottery and dies, it passes on to their heirs or something - I imagine the lottery companies have a way of recouping if that person chose the lifetime payments over the lump sum. (Come to think of it, that's a mental model I should update; "consider the lump sum for reasons that go beyond the utilitarian calculation of the total amount.")

Anyway, I lived in this particular iteration.

Subsequent tests in the ER showed no major artery damage (which was a concern based on where my leg was pinned). Then, my calf started to get tight and red and warm... an indication of a potential clot. Another ultrasound later, no clot.

I escaped with just some very intense bruises. One was shaped, amusingly, like a t-bone steak.

### Three: Reflections
First, it's amazing how "narrowly escaping death" feels very much like a routine event. I don't know how much more it would have _hurt_ to die. Being an American citizen, after going to the ER, I went and ate cheesecake and watched fireworks that night at my sister's farm house.

It's odd to "get on with life", but the alternative seems worse: to bask in the nearness of death. And so things continue on with some regularity. I realized that people barely pause for you; and why should they? They themselves are living their lives, why should I take some of theirs?

I'd also like to say that the experience made me more patient, less easily frustrated, more grateful on a moment-to-moment basis. But, in honesty, I haven't noticed a major difference in that. Maybe it takes more near-death experiences, or maybe being frustrated sometimes is just normal.

I already think about death a lot. I have not yet reached the point in life where my fear of death is outpaced by my fatigue with living. I grew up in a (very authentic and loving) religious atmosphere. I make quite a few concessions about death to myself to try to deal with those thoughts: _there is nothing you can do, so why waste your time thinking about it? Millions have died before you. If you grieve what you will miss, you should also logically grieve what you missed before._

These thoughts masquerade as comforting, but are in fact distractions from the inevitable unknown eternity.

However, simultaneous to my darkest existential dread, I feel an overwhelming sense of gratitude. (Not in the every-minute, as I already mentioned... but in the reflective part of me.) For the confluence of factors that led me to where I am today, with the life I have to live.

### Four: Resolution

I'm convinced that part of our psyche is built to overindulge in what-ifs, and that it gets magnified in situations like this. I assume this is part of our natural survival learning so that these kinds of things don't repeat themselves. You see a tiger in that cave, you don't go back to that cave - that sort of thing.

The feeling was nothing short of anxiety-overwhelm thinking about what almost happened, what could have happened had any small variable been different.

The night after the accident I stood staring at the gym floor covered in haphazard, awkwardly balanced equipment laying everywhere. I stared mostly in awe. Every new glance, there was another reason or avenue for me to have been maimed or killed.

I think our brains don't really fully parse when a threat is no longer active. I don't know much about PTSD, but intuitively I imagine this is at least a component for some; even though the falling equipment was no longer threatening me, I still felt fragile.

And then it hits me: I *am* fragile. I make mistakes. In the grand scale of everything, this is just a whisper.

That feeling of fragility is at first uncomfortable. But then it becomes, in an odd way, comforting. We all are bound together by our fragility. Not just between life and death, but in everything we do.

I looked at the crossbar that saved my life; had it not been there, I wouldn't be here. The weights on the floor that could have fallen on my head. The bars horizontally that could have twisted and broken my legs like pieces of uncooked spaghetti.

Then, we cleaned it up.

My lovely wife helped me set the gym back up. We didn't just restore the functionality - we made it safer, and even upgraded it. Better space I've already gone back down to work out.

For me, this is resolution.

The Day I Almost Died


Today in the Guild company chat, someone brought up the [[Ship of Theseus]]. The idea is simple: take a given ship. If you replace one part, most reasonable people would say that's still the same ship.

But now, replace every part, one by one. Even better, replace some parts twice.

Is it still the "same ship"?

There isn't a correct answer to this problem. A deconstructionist would say there is no ship. In fact, there's also no wood. Everything is just molecules, and the fact that they happen to be near one another is not scientifically meaningful. The ship, therefore, exists _only in your mind._ You _give_ it meaning, and therefore the only answer is the one you provide meaning to.

The hallucination trick is that we have a shared meaning of the ship - that any other given person you ask about the ship would agree that indeed, that is the Ship of Theseus. The collective agreement on the meaning makes it something more than a simple hallucination. But, the hallucination breaks down differently under change; _"is it still the same ship?"_ has less uniform adherence than the original concept of the ship.

## Testing doesn't exist

This discussion reminded me of another discussion I had recently with a colleague about test strategies.

Most software engineers have as many or more opinions about testing as they do about programming paradigms or cuisine. What shape is your testing strategy? Is it a trophy or a pyramid? Do you do real E2E or do you stub out the services? What is your coverage percentage? Do you test integrations directly? Do you test your private code? Unit tests? Feature tests? Do you automate performance regressions?

Don't get me wrong - these are excellent conversations to have. Often, the most seasoned engineers I know spend more time focusing on writing tests than the code being tested. (This lines up with the reality that code is not the bulk of the work you do - it is just the outcome.)

But if you put two engineers at a bar to resolve to the best testing strategy, there's a close-to-certain chance it will end in a stalemate. Add a third engineer to the mix and you've almost created a perpetual motion machine.

Testing doesn't exist, in the same way that the ship doesn't exist; not because we're replacing the code constantly, but because testing in all of these formats is essentially "more code" (or, in some cases, more button clicking).

What exactly is it that exists? What are the molecules here? Or, what is a more useful layer of abstraction that the 3 engineers at the bar can settle with?

## Testing As A Materials Tool

The concept that "testing doesn't exist" shouldn't be incendiary - of course the shared concept does exist. However, what happens if, like Theseus's Ship, we replace some unit tests with some other kind of test... or, more to the point, if we adopt a strict type-safe approach that eliminates the need for some of our unit tests... are we still testing?

Instead of thinking about testing as a primary mode, it is more useful to think about testing as a variety of tooling. Your intent, then, is to think about and manage risk.

How do you decide whether to do a unit test? Risk modeling.
How do you decide whether to do manual tests? Risk modeling.

What about feature tests? Trophy? It's all the same. The value of testing is to reduce risk.

## "But Testing isn't Just About Risk"

"It's also great documentation," you say, sitting back and sipping your pourover. Yep, sure - the same concept exists here, though! Documentation exists to _reduce risk!_

Your new engineer onboarding and reading tests to understand what's happening? That learning reduces the risk that they will change something in a dangerous or unproductive way.

So, even for tests that don't directly increase confidence (which carries a loosely inverse correlation to risk), they are still also reducing risk by creating clarity around how your code works to other human beings.

## Okay... Enlightenment achieved, everything must be about risk?

No. This is just a useful mental model and thought exercise. I don't actually believe documentation and testing don't exist. This is just a way to determine whether your tests and documentation are actually useful or not.

If your tests are not reducing risk directly or indirectly, what are they doing?

## Testing as a Cost Center

Testing in this model can be considered a cost center. If you could achieve equivalent risk reduction _without_ automated or manual testing, why wouldn't you?

Many cost centers are risk reduction mechanisms. Some types of employee benefits (but not all) fit into this category.

For example, unlimited vacation time might be used to reduce risk of employee turnover. There are two sides on this coin; vacation time is also correlated with higher productivity, which also has a positive effect on retention. Calibrating the amount of vacation time, then, becomes an exercise in understanding risk. Too little vacation and you risk burnout and turnover; too much vacation and you theoretically risk too much interruption. The "right" amount is dependent on many factors.

As it turns out, you can nearly 1-1 replace choice words in the above paragraph with testing. Let's try it:

> For example, testing might be used to reduce risk of shipping bugs to production. This is two sides of the same coin; testing is also correlated with higher productivity, which also has a positive effect on quality code. Calibrating the amount of testing, then, becomes an exercise in understanding risk. Too little testing and you risk quality issues; too much testing and you theoretically risk shipping too slowly. The "right" amount is dependent on many factors.

## Okay, I buy it, but I'm not sure how this is instructive.

This isn't directly instructive; rather, this should provide a north star for your testing efforts.

If your testing doesn't reduce risk, why are you doing it? Note that we're talking both about current risk (ensuring what you wrote works how you think it works) as well as future risk (ensuring that any future code you're writing doesn't regress existing test cases).

Risk reduction will, statistically, result in a reduction in adverse events. Risk in its simplest version may be described as "the probability that something bad might happen."

Perhaps the risk you are reducing has not materialized yet into anything bad. You are going from a 1% risk to a .01% risk. It's possible (but improbable) that you are writing tests to reduce a risk that has never materialized into an adverse event.

In any case, the instruction here is to measure the usefulness of your tests by the risk reduction factor.

"How does this testing work help us avoid something bad happening?" - When you are in your sprint refinement sessions, this is the question a good engineer will ask about a beefed up testing effort.

## TDD and other reasons for testing

Remember, what we're talking about here is only _one_ valid lens for the purpose of testing.

Another perfectly fine lens is to view testing as a creative tool. TDD (test-driven development) and other similar processes involve testing as a core part of the code writing, asserting that writing a test first jmay help ensure that the code written meets exactly the requirements.

It's worthwhile to ask why you would want to do this. Why would you want a developer to write only the code necessary to fulfill the testing requirements?

A few possible answers:

- It creates a clarifying mechanism for the requirements
- It ensures the developer is not spinning their wheels on things extraneous to the core requirements
- It disambiguates the translation between requirement and implementation
- It helps find product cases that may not be obvious when reading requirements directly

TDD is a solid creative process. Additionally, all of these are desirable from a business perspective _because they reduce risk._

## Wrap-up: Testing is about risk... but testing carries risk.
The most interesting insight I hope you gain from this article is that dogma surrounding testing may be dangerous, because dogma ignores risk modulations.

In other words, if you are testing to fulfill the "modern software testing requirements," you are missing the point.

Testing reduces risk, but it carries its own risk. Incorrect tests could instill a false sense of confidence in broken code.

Every activity you engage that involves code carries risk, and great engineers find multi-factorial ways to reduce that risk.


Testing Is A Shared Hallucination About Risk


Our family dog, Evie, ate my daughter's toast off of the table. This is a common occurrence - she will take whatever scraps she can get, despite risking the verbal assault that may follow.

This last occurrence triggered a thought for me, after a quick conversation with my wife.

"It's not the dog's fault." I said this without thinking too much about it. In this post I'm going to follow the chain of "fault-finding" as an exercise in understanding that finding fault is, mostly, an exercise in vanity and subjectivity.

It's the dog's fault. The dog is ultimately responsible for her actions.

It's not the dog's fault, it's the children's fault for leaving the toast out. The dog does not understand anything other than "toast, good."

It's not the children's fault, it's actually _our_ fault, because we haven't adequately taught the children to not leave the toast on the table. We also haven't adequately trained the dog to not eat people food.

It's not actually our fault, we haven't had sufficient incentive or available resources to train the dog, which is the fault of the dog trainers who haven't chosen to provide an accessible service.

It's not the dog trainers' fault, it's our fault for living in an area where dog trainers aren't readily accessible... or maybe it's the fault of the local market, which has not created sufficient demand for dog trainers.

Or maybe it's back to our fault for living in an area that doesn't create the demand for dog trainers.

Or maybe it's the fault of the economic paradigm we live under, which requires volume of demand in order to justify a given service availability to capitalize sufficiently to make a profit.

Then maybe it's the fault of the systems that perpetuate the capitalist society... those who are in positions of power to perpetuate the economic system that benefits them.

Or maybe it's the fault of the policies that allow for that system to be capitalized on in the first place... the politicians.

Then maybe it's the fault of the voters. But that gets into a vicious cycle where it's the politicians' fault again, since they are manipulating their voters or the voting systems with gerrymandering, propaganda, or echo chambers.

Then we should blame the politicians' parents, as they did not instill in their children values to guard against these manipulative practices.

But perhaps that was a product of their environment - the silent generation. They experienced the great depression, and later, the Vietnam war. Maybe their trauma is to blame for my dog eating the toast.

But then, we have to blame human nature itself, the underlying cause for many of these links in the chain, including the Vietnam War or The Great Depression. But the Great Depression was also partially caused by a drought - no direct human involvement there.

Do we blame the whims of the weather system then? All weather is the result of energy exchanges, and all energy on earth is derived from the sun.

So it's the sun's fault.

Or...

The existence of the sun isn't just an eternal truth. According to Nasa.gov:

> The Sun formed **about 4.6 billion years ago** in a giant, spinning cloud of gas and dust called the solar nebula. As the nebula collapsed under its own gravity, it spun faster and flattened into a disk.

The nebula collapsed under its own gravity as a result of the explosion of a nearby star - a supernova. (In a fun turn of events, my daughter's name is Nova.)

So we blame spacedust and dying stars.

And those came from... the flinging of all things into spacetime by the big bang.

And beyond that, all that's left to do is blame God or the universe for my dog eating the toast.

Unless of course there is more than one universe.---


The Dog Ate the Toast Again.


If you are a beginner manager, you will get a ton of advice for how to manage
teams, and probably just as much about how to manage individuals.

A lot of it will be paper-thin opinions; much will be useful in certain
scenarios.

Then other advice you will receive is _irrefutably true._ It's not so much
advice as it is logical explanations. I hope this fits in that category for
you.

This advice is targeted primarily at the individual, though some form of it
could be applicable to abstract entities like teams or companies.

(By the way, I can't take credit for the origination of this idea; that credit
belongs to Andy Grove.)

If you take nothing else away from this post, let it be this:

<Blockquote>If you want someone to do something they aren't doing, there can only be two reasons: they can't, or they won't.</Blockquote>

These are not mutually exclusive; sometimes they can, but they won't. Sometimes
they can't, but they would if they could.

Sometimes they can't _and_ won't.

Regardless of the person or circumstance, one of these must be true if they are
not performing some behavior.

Andy Grove then goes on to say that the only responsibilities of the manager,
then, are to train (alleviate "can't") and motivate (alleviate "won't").

### What "Can't" means

If you want someone to perform a particular role, they may be incapable of
doing that regardless of the motivation to do so.

Some things are universally impossible. "Be two places at once." Other things
are individually impossible. (For me, being bad at basketball is simply a
physical reality.)

Importantly, "can't" isn't always a dead end. For most business applications,
"can't" can be solved given the right resource allocation. Time and money
towards training, for example.

Focus on the _real_ can't. "I can't manage that server" may actually be "I'm
not confident enough to manage that server." Training in this case is less
about teaching the person something they don't know, and more about helping
them discover a self-confidence they didn't have before.

Importantly, do not discriminate against different flavors of "can't." For
example, if someone's anxiety prevents them from speaking in public, that's as
much of a valid "can't" as someone who is physically incapable of speaking.
Your job isn't to rate the "can't" on its validity - that's discrimination.
Instead, your job is to determine if the "can't" can be overcome.

### What "Won't" means

This one is tricky.

When we hear "won't", we hear obstinance. Refusal. Active disdain. We hear
someone who is unwilling.

That is usually only a small portion of the population of won'ts.

Won't more often is attached to the environment of motivation:

- Lack of clarity of the desired action
- Lack of knowledge of the desired action
- Lack of recognition of their suitability to perform the desired action
- Lack of understanding of the stakes (both positive and negative) attached to
  the desired action
- Competing interests with more powerful incentives
- Sludge / friction that make the cost to achieve the incentive too high, or
  create inertia

It's important to understand that most people are not actively against
something you want them to do. If they are, that fits in this category as well,
and may still be a problem of motivation!

### The plight of the assumer

Too often, managers assume reports know what they want. They expect that a
report knows to deliver work at some specific cadence. That their engineer
knows to deliver a certain test coverage standard. The assuming manager will
constantly have issues of performance management.

Usually these people bemoan behind closed doors that their engineers "just
don't have what it takes." This ethereal "what it takes" criteria will make
hiring and scaling your engineering org an absolute disaster.

"They have what it takes" is more often a heuristic for "I don't have to do as
much work to define the expectations I have for them."

If instead you want to make the most of your opportunity as a manager, seek
clarity. Be clear about _what you want your reports to do_, and _why you think
they should do it._

If you are bringing this to them with empathy, it will sound like an
opportunity. If you are bringing it to them from a position of power, it will
sound like a threat. (Guess which one works in the long run.)

You are probably reading this because you "have what it takes." You
intrinsically hold yourself to a standard that you believe is higher than the
standard of others.

Until you can let go of your own standard as a "global" standard, you will
struggle to hire, retain, and grow anyone who isn't like you.

Ask yourself: what would it look like to hire someone who doesn't think the way
I do?

What would I have to do to support someone who isn't strongly self-motivated?
Do I have the clarity to explain what I want, and to create the right incentive
structures to motivate someone like that?

### Motivate and Train

If you are not finding yourself often returning to the themes of motivation and
training, you are probably leaving behind some of your reports. You may not see
the problems right away, but eventually you will have a performance issue that
you'll have to solve reactively.

Be proactive about motivation and training. Help your reports exceed, rather than
meet, the expectations you are setting. Get ahead of the ball.


Won't and Can't


As ChatGPT (and, inevitably, other large language models) explode onto the scene in late 2022, questions around content moderation become more imperative.

In fact, one such thread is the inspiration for this post: [Ask HN: Should HN ban ChatGPT/generated responses?](https://news.ycombinator.com/item?id=33945628)

At first, it seems easy to answer this question. Of course, we don't want bots clogging our human discourse! How can we ever know what is _real or fake_ if we do?

I don't want to discount the importance of the leap in technology these models are providing. But we should work to think clearly about the role AI, and more to the point, technology more generally, plays in our lives.

### The tools and their wielders

Writing is fundamentally entangled in technology from the start. The earliest writing in clay with sharp objects was the start; the sharp object was, in the simplest sense, an assistant to the writer, helping shape the clay in a way that other humans could understand the form and make sense of it.

And writing didn't change drastically (other than adding new symbols that reflected culture) for a long time.

And then, suddenly, the printing press. You know this story, but have you ever considered the printing press similar to AI? Not in the sense that it produces novel output given some input. But from a social standpoint, we went from knowing that a given piece of work was produced directly by its author, to some disconnected copy of a copy, typeset by some person we'd never known before.

How could we guarantee the authenticity? And indeed, this was the fear - particularly amongst religious groups; the printing press could be used to undermine the official religious texts. False prophets could easily print their own versions of the Bible.

And, of course, those same groups had access to the same technology. Now, it was possible to publish critiques broadly.

### It looks like you're trying to write a unique comment on the Internet.

But the point is, we've always had access to some technology. And it's both a scale and a spectrum. The scale shows a depth of involvement: how _much_ does it help? The spectrum shows different kinds of help. In the case of the printing press, that was helping with replication.

But other advances have been made on other parts of that spectrum. A dictionary might be considered one such advancement. No, it doesn't spell words for you - but it *is* technology that helps you spell correctly. Continuing down that same path, spellcheck (the red squiggly) helps with a similar task. But an amazing leap was made when we first saw grammar checks, too. Now, not only does your computer do the lookup in the dictionary for you, but it also assists to make sure the word you are using is the correct one given the grammatical context.

But perhaps the most salient experience most remember with an "AI assistant" is not from some dystopian movie, but in Microsoft Word, when they first met Clippy.

Clippy provided a new kind of assistance; it spied on what you were writing (with no malicious intent of course), and checked for patterns; are you writing an essay? A letter? A resumé?

Clippy could help. On the spectrum, Clippy acted a bit like a formatting secretary, and worked alongside its spell-checking and grammar-checking robot teammates.

```mermaid
gantt
dateFormat  YYYY-MM-DD
title Adding GANTT diagram to mermaid
excludes weekdays 2014-01-10

section A section
Completed task            :done,    des1, 2014-01-06,2014-01-08
Active task               :active,  des2, 2014-01-09, 3d
Future task               :         des3, after des2, 5d
Future task2               :         des4, after des3, 5d
```

### Is it a brain if its Bayesian?

These tools were built on, presumably, basic decision algorithms mixed with an extremely limited domain of knowledge. I say presumably because I didn't do a deep dive on the specifics, but also because it's only been possible to do more complex AI work recently, as processing speed catches up to our workload demand.

A Bayesian model, in all its simplicity, is also incredibly powerful, especially when chained with multiple other Bayesian models. We overestimate the complexity of the majority of rough decisionmaking. Simultaneously we underestimate the exponential growth in complexity when we start talking about more complicated decisions.

A good Bayesian model may feel "smart" - indeed, we call our home devices smart just for remembering and executing on a daily schedule, or other basic rules.

### The assistant becomes the thinker

I'm sure there is some record somewhere of teachers being afraid that our collective knowledge of how to spell would just degrade as a result of spellcheckers. In the same way that cursive died when typewriters became accessible.

But those assistants were taking responsibility for things we consider non-essential. That is, the spelling of the word doesn't change the _meaning_ of the word.

The shift in thinking now is that we have tools that blur the line between assistance and impersonation.

On the spectrum, something like ChatGPT stands out against the rest of the tools, in that it simulates something uniquely new.

With previous assistant tools, the intent was to provide some help on the "outside" - that is, to help the person formulate the words correctly. To spell them right, to replicate them, to make sure they've chosen the right words in context... But, in all of these cases, the fundamental composition of _thought_ was still done inside the person's own mind.

The large language model _seems_ to change this dynamic, such that the "machine" does the novel thinking.

But we know that the NLP algorithm is actually trained on - and this is the amazing part - the writing that all of those other assistants helped make possible up to this point. The LLM knows nothing other than what we've told it.

Early printers told printing presses what order to put the letters. Microsoft told Clippy what a resumé looks like. And we all, collectively, told ChatGPT what order words tend to come in.

And so now, you "ask a question" and ChatGPT "answers" - in fact, that's not what is happening behind the scenes. ChatGPT looks at words and predicts the next most likely word.

### Not so special

This is not all _that_ different, in the universal sense, than what Clippy did. We provide some input, it provides some output based on processing our input against some rules it has. It just so happens that we're _very bad_ at detecting the difference between language coming from a prediction algorithm vs language coming from a person. (To be fair, I should give significant credit here to just how good ChatGPT does with this prediction.)

So it seems one or both of the following must be true:

- We overestimate how unpredictable our language is (especially given enough samples)
- We underestimate the comprehensive capacity of neural networks to approximate the process of speaking/writing like a human

I believe both are true. The ruleset Clippy had, though, was more "robotic." Interestingly, the same concerns aren't raised about other predictive algorithms with similar levels of accuracy.

Self driving cars, search engines, or price prediction algorithms are all sophisticated to similar degrees as ChatGPT. The _scale_ is similar, but the _spectrum_ is different. The jobs performed by driving cars only feel vaguely human. The job performed by a price prediction algorithm doesn't feel human at all - it represents a fundamentally new capability. There is little sense of concern attached as a result.

### An illusion

If you see a comment that is valuable on a hacker news thread, to what level does it matter that the comment was generated? There is both the intrinsic and extrinsic value to consider: intrinsically, something might feel wrong to some people about allowing generative text algorithms to participate in an otherwise human discussion.

Or perhaps more directly, allowing generative text algorithms to _trick us into thinking they are human._

The extrinsic part deals with the system created around these conversations. If ChatGPT begins to earn karma, what does that mean about the value of karma on HN?

If part of the value of HN is that it is curated by humans, the karma gathering by bots also means the ordering of the top posts would be influenced by those same bots. Extrapolating, if someone were to train a bot on the karma system, we could feasibly expect that the bots would be able to "take over" HN by posting based on a language model that is specifically optimized for karma.

This wouldn't be an autonomous process - ChatGPT, or any other hyper-optimized bot - has no "intent" other than what we give it. I am an AI optimist.

### The problem with AI assistance is actually just humans.

But I am not an optimist when it comes to human moderation. The challenge we have in front of us is not a fight against AI.

Instead, these powerful assistants will likely result in faster optimization of messaging echo chambers. People, right now, are looking for ways to use this tech to quickly create monetization pathways for your attention.

But! Much like the days of the printing press, we have the same tools. We can use them for good rather than for nefarious at-all-costs profit-seeking.


The Spectrum of AI Assistance


In my experience, most workplaces fall into three categories with relation to "work-life balance." (Ugh, what a bad term for such a broad subject. I use it here because it communicates roughly the concepts I am writing about in this post, but I do wish to split hairs a bit with why this term is incomplete at best, reductive at worst. But we'll tackle that semantic debate elsewhere.)

### Type One: The "fast-paced" workplace

Generally speaking this is code for erratic schedules that bleed past your otherwise "normal" time boundaries.

I've encountered a few workplaces that even directly state that they work an average of 60 to 80 hours a week.

The "fast paced" reference is to the unexpected pace of demand. Usually, these organizations are not structured to normalize incoming demand, and instead are structured to build and grow as quickly as possible, even when growing risks malignancy.


### Type Two: The "has a good work-life balance" workplace

Sometimes these are the companies that truly have some modicum of respect for peoples' lifestyles. Usually, this means that you have a significant self-responsibility to set your schedule. You'll work tightly with your manager to determine when you can be out without hurting your team.

Sometimes, "good work-life balance" may actually translate (roughly) to "we have an on-site chef, mental health resources, and transit credits to help soften the sting of late night pager duty."

These companies tend to also have unlimited vacation policies.

These organizations typically fail to set clear expectations. The passivity of "unlimited vacation" has been [discussed at length](https://www.facet.net/posts/why-we-ditched-our-unlimited-vacation-plan) in many other forms for this reason; the result is that people do not feel the necessary permission to take vacation, and ultimately end up taking _less_ than their more traditional counterparts.

The failing here is that defining what should be accomplishable, and providing flexibility "assuming all your work has been completed" is a backdoor way of overloading a role, even unintentionally.


### Type Three: The "strict 40-hour a week" workplace

Interestingly, the strict 40-hour a week might turn out to be the most humane policy on this list, albeit with its own shortcomings.

Most older organizations are run this way, typically because of long-established policies.

The basic idea is that you are paid for five 8-hour days. You can take vacation based on the same time currency.

Your time is yours to manage; you use vacation as a resource. When you don't use it, you don't lose it - it typically accrues.

In a system where 40-hours is the established norm, generally a reporting and surveillance culture is assumed. Even when this surveillance seems ignored, the HR processes surrounding the accounting will feel a bit like fulfilling a contract, missing the sense of flexibility and relationship you might experience in a "good work-life balance" workplace.


### Shortcomings

Each of these three models has its shortcomings. In a fast-paced environment, workers burn out and tempers run hot. People feel the chaos of the role, and especially in remote environments never feel totally unplugged. In the "balanced" environment, everyone walks on egg shells. Trust is eventually accomplishable, but it might take years of uncertainty or anxiety to get there; this is even more pronounced for people early in their careers. The 40-hour week is, ironically, quite inefficient; it assumes that work can fit neatly into those 40 hours, which is often not true. Additionally, its easy to feel that your job is transactional, not a process of developing mastery or artisanship.


### The 39-hour week

Taking from each of these models, we can build a better way.

Instead of setting a strict number of hours for working, we set a soft ceiling at 40 hours.

But, we know that things will happen. Life doesn't fit in whatever boxes you make for it.

If it's 2PM on a Tuesday, and the weather is nice outside - wouldn't it be great if we could go stand outside and take that in? Why should all of our 2PM's be claimed except for on the weekend? This is where the 39-hour-week comes in.

We adopt the flexible demand mindset of the "fast-paced organization" - you determine what hours are optimal to work for you and for the job you're doing.

We adopt the trust model of the balanced workplace. You won't hear "as long as your work is done" - instead, you'll hear "the work can wait if it needs to."

We adopt the predictability and agency of the 40-hour workplace. Just because there is some flexibility in how your hours play out doesn't mean you don't have a clear picture of how things are going.

### TLDR;

Your job is not to fill a specific number of hours. It's also not to overextend and commit your whole being to the company. We won't passively guilt you into working as much as you think is "enough." Instead, we set an agreement - that you will seek excellence in your job, but you won't sacrifice your personal life to do it.

It seems so simple, but making the personal health of the individuals in your organization a priority will create a work environment that is magnetic.


The 39 Hour Work Week


<blockquote>
  <div class="inner">
    Get the fundamentals down and the level of everything you do will rise.<br/>
    - Michael Jordan
  </div>
</blockquote>

One of the most consistent messages you will find from world-class performers is a refocusing on fundamentals.

The intuitive mental model for this is that _experts_ will focus on _expert things._ That somehow the information they are consuming has transcended the information a beginner might be dealing with.

But over and over, we see this is not the case.

Intuitively we might imagine that a monk that has meditated for an order of magnitude more time than us might no longer need to focus on their breath.

And yet, what we know about transcendence from those same monks is that the effect is not a zooming up or out of these fundamentals, but instead, _in._

Our technique is not about building on top, but building within.

Josh Waitzkin describes this in more detail in his excellent book, [The Art of Learning](https://smile.amazon.com/Art-Learning-Journey-Optimal-Performance/dp/0743277465?sa-no-redirect=1). In the book he describes how his growth as a chess player was about finding the multitude of sub-second moments. He describes this as time slowing down, each twitch of his opponent giving him a world of information about the next move he might make.

This is not to say that more abstract information does not exist, but rather that it is an outgrowing of those same fundamentals, not some graduation and departure from them.

If you need a heuristic for whether you are on the right track, consider whether that track is leading you to abandon fundmamentals.


The Paradox of Transcendence


After fighting a bit with my work-issued computer not wanting to build my Gatsby site, I finally decided to bite the bullet and
build out a Docker image.

For those who are interested, image transformation was somehow tripping the malware blocker, causing a `SIGKILL`.

After trying (and failing) to fix this, I finally decided to fix the problem with a more permanent solution.

However, the "official" Docker image for Gatsby is a bit behind and hasn't been updated.

Here's the Dockerfile I'm using (named `Dockerfile.dev`).

```docker
FROM node:alpine

# Also exposing VSCode debug ports
EXPOSE 8000 9929 9230

RUN \
  apk add --no-cache python3 make g++ && \
  apk add vips-dev fftw-dev --update-cache \
  --repository http://dl-3.alpinelinux.org/alpine/edge/community \
  --repository http://dl-3.alpinelinux.org/alpine/edge/main \
 && rm -fR /var/cache/apk/*

RUN apk add automake autoconf libtool nasm

RUN npm install -g gatsby-cli

WORKDIR /app
COPY ./package.json .
RUN yarn install && yarn cache clean
COPY . .
CMD ["yarn", "develop", "-H", "0.0.0.0" ]
```

And here's the `docker-compose.yml`:

```yaml
version: '3'
services:
  web:
    build:
      context: .
      dockerfile: Dockerfile.dev
    ports:
      - "8000:8000"
      - "9929:9929"
      - "9230:9230"
    volumes:
      - /app/node_modules
      - .:/app
    environment:
      - NODE_ENV=development
      - GATSBY_WEBPACK_PUBLICPATH=/
```


This pulls almost directly from Daniel Stout's setup, which I found [here](https://dev.to/stoutlabs/my-docker-setup-for-gatsbyjs-and-nextjs-5gao).
(Turns out Daniel is also somehwere in TN.)

Running the image:

```
docker-compose up --build
```

Note, I had to go through some fiddly things that required installing the automake stuff. You may not need that line, but I did.


I plan to keep this `Dockerfile` updated as I continue to invest in this site, which is [open source](https://github.com/jcutrell/jonathancutrell).


Using Docker for Gatsby local development


## My perpetual goal is to build a better thinking machine.

I've gone back and forth on this for a long time. What do I want to get better at?

The answer has jumped around a lot over the years.

"I want to learn more unique skills."
"I want to learn more programming languages."
"I want to learn how to be in touch with my emotions."
"I want to learn about history... or philosophy."
"I want to learn algorithms and do a bunch of leetcode."
"I want to learn woodworking."
"I want to learn about nutrition."

This is a _very_ short list in comparison to what I actually "want" to learn.

But none of these captures fully what I want to consistently invest in.

I want to build a better thinking machine.

### A short diversion about thinking

I have this model in my head (I assume it is not novel) of how thinking works.

You start with some kind of shape carved out in your brain-stone by millions of years of evolution, and that shape gets opened up over the course of the first 25 or so years of your life.

As you experience new things, those experiences are like water flowing over that shape. Sometimes the water flows fast, others slow. But it always changes the underlying shape.

And as that shape changes, the flow of the water changes as well. It's a symbiotic relationship: the flow is changed by the shape, and the shape is changed by the flow.

What's more - we can observe all of this, and even redirect the water flow. (This doesn't happen without some difficulty or unexpected results, but nevertheless, we can _think about thinking._

### I want to build a better thinking machine.

In a meditation Sam Harris published as a part of his _Waking Up_ course, he mentioned the idea that our **minds are the only tool we have.**

This stuck with me, and I've been pondering this quite a bit.

If our minds are the only tool, then what are we doing when we _work on our minds?_ This self-sharpening relationship is interesting on a few dimensions.

The water/shape relationship, self-sharpening - all of this reinforces the idea that any investment we make in our minds as thinking machines will have a compounding effect.

(I'm very motivated to seek compounding effects.)

### What exactly makes a good machine?

A few qualities I'm seeking out here:

- **Plasticity** - this protects the possibility of continuous improvement. Imagine the erosion of the water just stops. Now, no matter what information or experiences hit your mind, your mind stays the same. This is a point-blank limiting factor.
- **Flexibility** - I would rather be able to think well about novel subjects than think perfectly about one.
- **Practicality** - I don't want to get stuck in the loop of perpetual study with no measurable impact based on my personal values.
- **Collaborative perspective** - One thing is for certain: we cannot develop complete thinking machines on our own. Our biases may or may not be influenced, but seeking collaborative input will always yeild more balanced results in the long run, assuming a random selection of individuals.
- **Full-body thinking** - I am guilty of being too cerebral at times. I'd like to develop thinking as a _part of my bodily experience_ rather than trying to create a supercomputer sitting on my shoulders.

### Some things I'm trying

- Meditation - my goal with meditation is to clearly observe my thoughts. Rather than being caught in the flow of water through the shape of my mind, I'd like to watch that flow as an observer.
- Diversity of experience - seeking new experiences (both in the physical world, and in the media I consume)
- Physical labor - reconnecting with the physicality and experience of developing and collaborating with the world around me
- Revisiting and pushing old skills forward - following well trodden paths and attempting diversions to re-develop skills I had once felt were solidified

Frankly, I don't know what will work and what won't. But of all the things I'd like to learn, I believe learning how to think more clearly is an evergreen goal I can get behind.




Thinking Machine


Talking about remote work is en vogue right now, and rightfully so. Coronavirus poses
a threat to workplaces around the world, some countries announcing full lockdowns. 

Combined with the reality that [most Americans don't even have enough saved to cover a
$1000 emergency](https://www.cnbc.com/2019/01/23/most-americans-dont-have-the-savings-to-cover-a-1000-emergency.html),
it's untenable to expect people to stop working for an extended period.

For many, the answer will be remote work. More companies will adopt this practice, whether
as a result of Coronavirus or not.

Most of the writing that's happening on the subject is tactical in nature: how do you _survive_
a couple of weeks of remote work? This is important because it starts the conversation, but
it's not enough.

We need to be thinking what this means in the long run - months, years down the road.

We know something as simple as desk dividers can cause major changes to our productivity
and working culture. How much more will remote work affect your company?

That's why I decided to write a series of posts on this subject. In this first part,
I'll talk about some often ignored or invisible realities about remote work. In the
next few posts, I'll outline some playbooks for remote work that are built to last.

### Some invisible realities of remote work

#### 1. Everyone's working environment will be different (and that's okay)

Even the smallest changes to your environment can make a difference. We know, for example,
that an open office environment has totally different dynamics (some good, some not so much)
from private office spaces.

When you have everyone's environment changing simultaneously, these variables are different
for every person. What's more, these variables interact. This has a network-level effect.

To make this more tangible, think back to the last time a coworker joined a remote
meeting with a lot of noise in the background, or with a big lag on their computer.

Our individual environments have an effect not only on us, but also on our coworkers.

#### 2. People are not wired for remote work by default; It's a learned skill

It's not that we are incapable of adapting, or that there's some sacred connection that
we can't evolve past. But our biological processes haven't kept pace with our technological
advancements.

In plain terms, we still have bodies and brains that are optimized for in-person communication
and collaboration. When we try to apply our default communication models to our remote
environments, we handicap the communication process.

We'll talk more about this in future posts, but the immediate heuristic to reach for: increase
bandwidth. Whatever you can do to increase the amount of information that is communicated &mdash;
and specifically, the number of modalities you use &mdash; the better.

Use video, audio, text, emojis, and anything else you can to increase your bandwidth.

#### 3. We don't always know what we need

It might make intuitive sense to get out of bed and roll straight to your computer. After all,
this is an easy way to conserve energy, and gives you extra time to get stuff done, right?

We think we know what we need to be productive, but we're often wrong.

We think we need more time, but we might actually do better with more rest.

We think we need to reduce our energy spent, but we might be better off if we spent _more_
energy in _different ways_.

If remote work is new to you, you might think you know what you need to succeed, but be open
to learning, both from others who have done it before you, and from your own experiences.

#### 4. Your working equipment doesn't define your experience, but it _can_ throttle it

This is a very tactical reality to consider. If your machine is making your life difficult,
for remote workers the machine you use is essentially your direct conduit to work. For engineers,
the machine is essentially your whole workplace.

If you are a manager, ask about the experience your remote workers have on their machines.

(The same goes for dev experience in the codebase, but your equipment is the top-level
throttle; no matter how good the codebase experience is, if your machine sucks,
that throttles everything else.)


Patterns for Long-Term Remote Work


Modern workplaces are being forced to respond with caution as COVID-19 spreads worldwide. As of the writing of this post, over 100k cases have been confirmed.

Many companies are responding by telling their workers to work from home while we figure out what to do next.

I'm intrigued by this as a remote worker; a behavior that is unusual and difficult for a large group of people is a chosen mode of operation for others.

Companies that embrace a geographically distributed workforce already understand this.

Last year [on an episode of Tim Ferriss's podcast](https://tim.blog/2019/07/03/the-tim-ferriss-show-transcripts-josh-waitzkin-how-to-cram-2-months-of-learning-into-1-day-375/), Josh Waitzkin (the subject of the movie Searching for Bobby Fischer) talked about _boiling_, a technique for practicing foiling (a challenging type of high-speed surfing).

An excerpt from the episode:

> Most people, if they’re foiling, you don’t have many chances to train at boils, and when they happen, it’s just catastrophic. It’s a massive wipeout. Now, I did two sessions where I went over 200 boils at top speed. It’s doing tons of reps of boils or tons of steep sections. The learning curve is incredible.

Josh's choice of surfing into the boil seems crazy at first, but he knows this will result in a much better outcome.

This concept runs deep in [antifragile](https://smile.amazon.com/Antifragile-Things-That-Disorder-Incerto/dp/0812979680?sa-no-redirect=1) thinking: how can I use the exceptions, difficulties, disorder, etc to become _stronger_? Instead of simply recovering, or taking the blow - how can we improve as a direct result?

Remote work isn't the same, necessarily, as boiling. Boiling is mostly an exercise of stress-induced growth, while remote work is a different _modality_ of work, but some similar principles apply.

We don't choose remote because we are forced into it. We choose it because of the advantages it provides.

[The first thing I get on a quick search about remote work studies](https://www.inc.com/marcel-schwantes/new-study-reveals-why-working-from-home-makes-workers-more-productive.html) praises the positive effect of remote work on morale. I [tweeted about this](https://twitter.com/JCutrell/status/1235376215910989824) and people shared some clear advantages to their personal lives.

### Remote isn't "easy" on day one.
Don't take me wrong - I'm not trying to preach to non-remote companies that they should change.

Remote work can feel isolating. It isn't our "natural way" - we lose a lot of bandwidth in communication when we're representing ourselves through a few words on Slack or a 5 minute Zoom call. This is not easy.

I'm interested in exploring this interesting gap between chosen pathways resulting in antifragility, when the same chosen pathway is a threat when it's forced.

I'm interested because I want to know what other places we can seek out pathways we otherwise would avoid. What exceptions should we invite? What stress should we use as a pathway towards antifragility?


How Remote First Companies are Antifragile


Shortcuts are a special kind of tricky. It's critical to be very careful about what shortcuts you take.

Here's why.

### Shortcuts often compromise in ways that are not explicit

Our mental model of a shortcut is "arriving at the same place with less distance traveled." The visual model most people have is like a hidden side road that goes directly from point A to point B, cutting out the unnecessary trip to point C.

However, in most practical cases, we aren't actually taking a true "shortcut" - instead, we are making a tradeoff. Sometimes that tradeoff is actually just taking advantage of the Pareto principle, reducing effort drastically while retaining most of the value.

Other times, the shortcut is removing measures like testing, documentation, error handling, or proper abstractions. The end product may have similar presentation, but the underlying foundation and structure presents future risk.

### Shortcuts carry skewed social rewards

Imagine a picture taking a shortcut in your mind.

Got it?

Does the person taking the shortcut in your mind know something that others don't? By necessity, this cunning, clever move sets you apart socially from the rest.

If you know about a special sequence of backroads that isn't obvious, you are in an elite group of people.

The same kind of social reward skewing happens when a company has a codebase that is confusing to newcomers. This gives the "old guard" a sense of gatekeeping authority and a false sense of excess competence, even though it would be better for the company to derisk the codebase for newcomers.

### Shortcuts are self-reinforcing

Basic conditioning is still one of the most important fundamentals in behavioral psychology. For shortcuts, we see a positive reinforcement:

> Behavior, reward, repeat behavior.

While the gratification of taking the long way is much less of a conditioning response:

> Behavior, delay, disconnected or distributed reward

This incentive naturally biases us towards taking shortcuts.

Sometimes, not taking a shortcut could induce a negative feedback loop:

> Behavior, negative feedback, delay, disconnected or distributed reward

Shortcuts are celebrated because they are seen as less expensive; however, this evaluation is usually done as a single factor analysis. In other words, what are the immediate costs?

If we evaluate the long term costs, both to our work and to our incentives, we are likely to rethink our addiction to taking shortcuts.

### Be careful with your shortcuts.

Shortcuts aren't always bad. Sometimes, we can actually get to the same outcome with less input. However, it's important to be explicit about the risks you're taking on, the value you are compromising, or the waste you are reducing.

We don't always get to _choose_ our incentives. Sometimes, our working patterns create incentives we aren't intending to create.

Take time to consider whether you are building incentives that lean towards fragility, or if you incentivize long-term thinking and procedures.


Be Careful Taking Shortcuts



I don't talk about it online often, but I've had my pilot's license for a few years now.

![My instructor, Tom, and I - The day I got my license.](./license.jpg)

As I progressed through flight training, I realized how applicable some of the mental
models a pilot uses are to software engineering. This was one of the first times that
I saw how important a mental model can be, and was immediately able to draw correlations
to my work as a developer. Here are a few of those models.

_Quick note: the models below apply to single engine propeller planes (which is all I'm trained
to fly). Conceptually they extend beyond that, but may be shaped a little differently for other
types of airplanes. But this article isn't really about flying anyway._

### 1. You can't stretch glide

This is one of my favorite mental models to talk about. It is based on a simple concept in
physics called [conservation of energy](https://www.khanacademy.org/science/physics/work-and-energy/work-and-energy-tutorial/a/what-is-conservation-of-energy).
Boiling it down to its simplest form, energy cannot be created or removed from the universe,
but this is also true for simpler isolated systems at a smaller scale.

An airplane is "gliding" when it is relying purely on _potential_ energy (in the form of height).
This happens when the engine is at idle, or (critically) when the engine fails.

The process of gliding to the earth is a simple transfer of potential energy into (mostly)
kinetic energy. Without getting into [too much detail](https://www.boldmethod.com/learn-to-fly/maneuvers/how-to-handle-a-power-off-landing-following-an-engine-failure-best-glide-or-minimum-sink-how-to/), flying at a particular air speed maximizes the efficiency of this transfer.

A common error in engine failure scenarios is an attempt to "stretch glide."
This often happens when a pilot is trying to make an emergency
landing, say, in a field, but realizes they are going to be short of that field (perhaps
heading for trees instead). They are gliding at the right angle to maximize their glide,
but then they make the critical mistake: **they pull back on the yoke.**

This simple gut-based reaction is the cause for many fatal accidents. The otherwise maximally
efficient glide is made less efficient, and against gut intuition, it _shortens_ their glide
even further. Pulling back hard enough causes a stall, usually too low to the ground to recover.

#### Lesson: Don't pull back on the yoke; it will shorten your glide.
Energy is conserved. When you try to work extra on the weekends or late nights,
you are pulling back on the yoke. Eventually, what feels like the right decision
(overworking and "hustling") will end poorly. Don't try to overrun your pace!
This is how technical debt happens, it's how testing gets skipped, and it's how developer
health declines.

### 2. The best pilots always use the checklist

There are a handful of behaviors that great pilots have in common. They can be summarized
by this: great pilots follow the checklist.

Aviation safety is heavily dependent on checklists. If a checklist is not followed, critical
mistakes can occur. For example, not long ago, a passenger jet crashed shortly after takeoff.
The reason? The trim was set for landing, causing too high of a pitch-up.
(This is a checklist item.)

Unfortunately, human ego makes us believe that somehow _not following procedure is a sign of
expertise._

Unfortunately, this is only _sometimes_ true. Not following a checklist because you have a nuanced
understanding and are choosing to do something different based on experience is not the same as
forgetting an item on the checklist.

More often than not, humans have a false sense of superiority.

- This is why we excuse ourselves from writing thorough tests.
- This is why we believe it's better to write our own package rather than relying on someone else's
- This is why we have a hard time predicting failure scenarios
- This is why we skip over documentation even though it probably has the answer to our question

#### Lesson: Ego is dangerous. Don't break the rules purely out of self-confidence.
There's not always a perfect procedure. But when a procedure exists, you are probably better
off trusting it by default, and departing only when you can validate your reasoning
beyond your own intuition. Even then, do so sparingly; breaking procedure is unexpected
behavior, so the developers who might encounter your work in the future may experience
difficulty if you depart from the normal path.

### 3. Always have a backup plan, even when the risks are low

Every flight I take, I am required to have at least 30 minutes of extra fuel on board.

If I fly at night, I have to have _45 minutes_ of fuel onboard.

It doesn't matter if the weather is perfect and there's not another single pilot in the sky.
It doesn't matter if I have 5 parachutes onboard and I'm flying high enough to glide across
the state.

If I file a plan to fly IFR (in the clouds with only instrument reference),
unless the weather at the destination is forecasted to be very good, I have to have an
alternate airport. I need enough fuel to make it to my planned destination,
then to my alternate, and then **another** 45 minutes.

Why? Because no one ever _expects_ an unexpected emergency. The cost of preparation is much lower
than the cost of disaster. "Better to have it and not need it than to need it and not have it."

What happens if weather does something unpredictable, and you have to fly to another airport?
What if an airport service vehicle breaks down in the middle of the runway,
and you can't land there? What if an earthquake splits the runway in half?

#### Lesson: Sometimes things don't go as planned.
And unfortunately, sometimes this ends in disaster. Planning is cheap.
Take the time and resources needed to prepare for the unexpected.

### 4. Pilot error is far more common than mechanical failure

In [a study published in 1984](https://www.ncbi.nlm.nih.gov/pubmed/6497826), human error accounts
for over half of all airplane crashes. Statistically that means human error accounts for more crashes
than _all other causes combined._ This isn't a failure of the system; this is a reality attached
with being human. We make mental errors all the time. (Remember model #2.) Being reminded of the
fallability of human effort helps us understand why we should try to rely on machines more than
ourselves when possible.

#### Lesson: When something goes wrong, assume it's a human problem first.
Typically we have a tendency to blame a tool or a process rather than a person. But humans - even
highly skilled ones - are most often the cause of failure for software. The sooner we can
acknowledge this, the sooner we can design our systems around human limitations rather than
denying them.


*The next four will be updated in the near future. Check back here soon.*

### 5. Thrust, Drag, Lift, Weight
### 6. The speed is the speed
### 7. Aviate, navigate, communicate (in that order)
### 8. Every flight is a lesson, so pay attention


What I Learned About Software Development in Flight School


I turned 30 on Saturday. Lauren surprised me by bringing our families together - my parents, her parents, my sister and brother-in-law, to celebrate that I've made it to 30 years.

It was a calm and peaceful mid-morning celebration; Lauren had tried for months to orchestrate a more momentous event, but from my perspective, we've had plenty of momentous events recently in our lives.

This year has been one of the most turubulent and change-filled years of my life.

That's saying a lot for a kid who grew up in a military family. We used to move once every four years or so, and staying longer in one place always made me feel unsettled, like I needed to change everything because that was the rhythm. Like some kind of instinctual migration.

This year, Lauren and I have experienced massive changes; I'll detail the big ones here.

### Phases of 2018

#### January - February

The beginning of this year was one of the most difficult periods of health anxiety I've ever experienced in my life. There were times where I felt like the whole world was falling apart. Part of my brain was convinced that I would never get a chance to talk to my son, because I was destined to die before he was old enough to hold a conversation. This took a major toll on my mental health, and I felt more depressed than I had in a long time. Around this time, I started therapy.

In the midst of my mental battle, Lauren's father, Ken Ritchie, was continuing his fight against heart disease that began the previous year with a stint procedure. During a full-torso scan to determine if he would be eligible for a new experimental valve replacement, a mass was detected on his pancreas. I remembered just how grim the outlook is for pancreatic cancer patients, knowing that this meant a long year ahead, and went into comfort/support mode (despite still struggling with my own anxiety).

#### March

Over the course of the next month, we decided to move from our beautiful small home in downtown Chattanooga to a larger home in Ooltewah, a bit out of town. We knew we wanted to have a larger home eventually, and decided now was the right time.

On the day we went to close on our old home, we found out that Lauren's father's pancreatic cancer was in fact a neuroendocrine tumor. Long story short, the chances of having this type of pancreatic cancer was a 1-in-20, and as it turns out it has an excellent survival rate.

We closed on our old house, but the new house had some strange code complications so we were displaced into a hotel for a week or so. Towards the end of the stay, we got a call from Lauren's parents in the middle of the night; her father had been rushed to the hospital. During the biopsy of his pancreas, they nicked an artery, causing an embolism. Lauren, Liam, and I got in the car and rushed to Atlanta, not knowing if we would see Lauren's father before it was too late.

We did arrive in time, and in fact Lauren's father pulled through this terrifying event. (I'll spare the specific details here.) The next day, we finally closed on our home in Ooltewah.

#### April

We spent Lauren's 32nd birthday here at our home. We got a projector for our media room and watched Planet Earth.

My sister, Janna, became Liam's Nanny. This was a very special period of time that she and we cherish closely, and I'm so thankful for the circumstances that allowed this to happen for a while.

#### May

Lauren's father had heart surgery to replace his valve. Yet another complication occurred, resulting in another internal bleed - and yet again, Lauren's father pulled through this event. Our son Liam was accepted into his school, Brown Academy in downtown Chattanooga, this same week.

Around this time, I also started to feel like my work at <a href="https://whiteboard.is">Whiteboard</a> wasn't the right fit for me any more. There were a list of issues, many of them quite common, some of them the result of personal changes. I didn't act on this feeling yet, knowing that my life was already throwing plenty of change at me, so I held on.

#### June

Lauren and I celebrated our 5-year anniversary. We had a wonderful time together in Chattanooga. Liam also turned 1 year old in June. We had a wonderfully normal 1-year-old birthday party at our home here in Ooltewah, and for a month or so we were able to relax and enjoy the summer warmth in Chattanooga.

However, for both Lauren and I, we had a growing sense that we needed to shift our careers.

#### July

In the first few days of July, Lauren's father underwent the Whipple procedure. This is one of the most intense major surgeries that a person can have, removing a significant portion of the pancreas. His surgery went without complication. Lauren and I spent the 4th of July in a hotel room in Decatur, Georgia with Liam, watching fireworks on TV and flashes out the window, extremely grateful and quite tired.

Around mid-July, I finally made the ultimate decision to leave Whiteboard. I received an offer from Clearbit, and accepted the offer. This was a massive shift in my life, which I will write about in other posts for the sake of brevity and focus; however, this was a pivotal moment in my career.

We took our first true family vacation in the last week of July. I flew our family to Hilton Head, where we spent the week decompressing.

On July 25th, Lauren's father was declared free of cancer! This was somewhat of a bookend to a nearly year-long battle that we fought together as a family. Amazing and unexpected things happen, and we are grateful for our fortunate circumstances.

#### August

In mid-August, I started my new position at Clearbit, spending a week in San Francisco. Lauren by this point had decided to move on from her position at Whiteboard, and began pursuing a position with <a href="https://soundstripe.com">Soundstripe</a> as their first Agile Project Manager. I had the opportunity to fly her to Nashville for her interview, and the next day, August 15th, she received and accepted an offer.

The day I returned home from San Francisco, Liam took his first steps! It was a memorable moment and a celebratory note amongst a difficult period in our lives together.

#### September

In September, we had a chance to visit my parents in Dothan. Understandably, we hadn't gone to Dothan very much this year, considering how often we needed to be in Atlanta to support Lauren's family.

Mid-September, Lauren fought off a stomach flu for about a week. We both settled into our new jobs, learning how to work with new people, new expectations, and entirely new business domains.

#### October

In October, a bucket-list item was checked off for me; I flew my family out to Albuquerque, New Mexico in our Cessna 182. This was a belated anniversary celebration; Lauren and I were engaged in Albuquerque, and I was born there. This was a very meaningful trip for us, and one I hope to repeat in the future.

To continue our medical saga, at the very tail-end of our Albuquerque trip, Lauren's eye became infected. She was diagnosed with a corneal ulcer. This is something that can legitimately leave you with compromised vision, but luckily she was treated and recovered her vision to its pre-ulcer status.

#### November

In November, we tried putting Liam into a school closer to our home in Ooltewah. This didn't go very well to say the least, and ultimately we decided to take him back to his original school. We learned a lot in the process, especially about our parental instincts.

Lauren was promoted in November to Director of Product at Soundstripe. This was a huge vote of confidence in her abilities, and I'm incredibly proud of her.

In late November, we also found out that we'll be adding #4 to our family of three. We'll be seeing the next Cutrell baby in late July or early August 2019!

#### December

In early December, Clearbit opened our brand new Chattanooga office. There are 6 of us Clearbit-ers in Chattanooga, and this office is an absolutely beautiful place to work. Once again, reminded of how incredibly grateful I am for the circumstances I've been afforded.

I turned thirty on Saturday. This seems like a footnote to the incredibly impactful things that have happened this year, but I am remembering to take each moment in. To not forget what's happening in small moments, and to love myself and others every day.

#### Things I didn't mention...

This didn't cover every single major event, by any means. But we've been offered a year of massive change in 2018. For example, this was <a href="https://spec.fm/podcasts/developer-tea">Developer Tea</a>'s most successful year since I started the podcast. Brian, Bryn, and Max had a huge moment of success when GitHub acquired Spectrum. So much can happen, and become eclipsed by the rest of life.

As my wife and I recounted this long list of events, we surprised ourselves with just how much has happened this year. It's amazing how fast life can happen around you. Take time to notice it.

### Takeaway Lessons

I've learned so much from this year. Some quick takeaways:

- Don't get ahead of yourself. Take things in stride; you can't predict what will happen in your life next.
- Humans are engineered and evolved to be survivors first. We adapt, we shift, we learn. Do this constantly, not only when it is required; remain flexible.
- Serious days don't prohibit happy moments. In the midst of difficulty, seek levity. No one is rewarded for how serious they are.
- Your work should not be limited by your employer. Changing jobs is normal, even if it feels difficult. Don't be rash with your decision, but remember that your career affects you more than any other person, and you have to be responsible for that.
- The line between sanity and instability is thin. Don't count yourself out on this; your mental health is likely more fragile than you think. Breathe deep, drink water, eat right, take walks. Give yourself time to simply exist, to be a human.

If you're reading this, I probably have a good reason to thank you. Whether you listen to Developer Tea, or you know me personally, the people around me are due a lot of gratitude. Coming out of 2018, I'm becoming a more grateful person, looking forward to an eventful 2019.


A year of changes

Open-ended responses require synthesis and are uncomfortable territory for students early in the learning process.

Humans are quite good at synthesis. However, sometimes we have trouble retrieving the right information at the right time, which may prevent us from responding as thoroughly as we are capable of responding.

What are some ways we can fight this retrieval barrier? Perhaps with a collaborative agent. In <a href="https://www.nature.com/articles/srep38580">a 2016 study</a>, Eugster et. al. were able to create a recommendation engine based on neural activity. This kind of observational recommendation has existed as long as search keywords have been around (and even before).

But what about in creative learning environments, where the goal is not merely interest and identifying well-worn paths from the current location? Furthermore, how might we avoid surfacing information that the learner is tasked with retrieving?

Setting up these guidelines is critical, as we know that learning depends on intervals of information retrieval and synthesis. So the strategy shouldn't lean into revelation territory.

<h3>The Power of Reflection and Suggestion</h3>
In the famous MIT project ELIZA, created from 1964-1966 at MIT's Artificial Intelligence Laboratory, we know that reflective responses (where the machine collaborator responds by restating the human collaborator's statements) are powerful. At the very least, ELIZA convinced the human collaborators that it was intelligent.

Of course, context must be taken into account. ELIZA was built specifically as a parody, and few people had been exposed to any sort of interactive computation of the sort at that point in history, so relative to the backdrop, it probably wasn't extremely difficult to convince people that the computer was quite intelligent.

However, ELIZA (and many examples thereafter) outline the power of a relatively static collaborator in opening up a person's thinking.

As a programmer, I use "duck debugging" on a regular basis - a process of forced, methodical articulation. When given a static collaborator (the duck), I am able to direct my attention to employing the method more completely.

<h3>Intelligent Collaborative Reflection</h3>
So how might we use collaborative reflection intelligently to help learners through an open response paradigm of engagement?

One way might be to create an intelligent collaborative reflection of what the learner is saying.

This might require a "processing" section - a scratch pad where a user might draw or type their thoughts as they process through them. With the encouragement that this scratchpad area is not being scrutinized, a student might use this area to explore information they are able to retrieve, visualize how the pieces connect, and formulate their ultimate synthesis that will end up in the "official" answer.

So how does our intelligent collaborative agent act?

Some ideas:

- Use some basic NLP to identify object tokens, and visualize those in a parallel screen. For example, "three dots" might show three dots of equal size in the parallel screen. The learner might be able to manipulate placement using text or direct input. This makes the text more than a human readable string; instead, it connects the words to a representational model.
- Provide a common vocabulary for generating visualizations or drawing relevance across a scratched narrative. For example, when showing a linear equation, provide the visual representation of that equation with a simple written syntax. Allow named variables so abstraction happens in the formalization step.

Of course, returning to our previous discussion, we want to avoid revealing information to the learner that they are trying to instill in their own minds; therefore, it would be necessary to provide the guardrails for what types of information may be reflected in a given circumstance. If the student is learning about 18th century European history, it's probably not going to help their learning process if they can easily query "timeline of the Seven Years' War" and get a visual representation of that.

Inferring what a user needs to see based on some set of guides could make a learner's mental processing of information much more powerful, allowing them to draw synthesis with a higher degree of depth. Educators may do well to provide better tools to the learner for the process of synthesis. In the same way that pencil and paper may create an externalization of ideas, perhaps it is time for a maturation of learning tools to extend our ability to articulate raw information for analysis and synthesis.


Collaborative AI Learning Environments: Show Me What I'm Saying

Believing is not adopting.
Hearing is not listening.
Changing is not innovating.
Saying is not being.

Talking is not leading.
Silence is not peace.
Technology is not inhuman.
Memorizing is not learning.

Trying is not doing.
Repeating is not diligence.
Opinionated is not stubborn.
Persuasive is not better.

Louder is not more powerful.
Simple is not easy.
Difficult is not complex.
Activity is not progress.
Toil is not success.

Power is not permanent.
Pain is not permanent.
Pleasure is not permanent.
Legacy is not permanent.

Perspective is not righteousness.
Seeing is not feeling.
Nearness is not intimacy.
Optimism is not irrational positivity.

Transparency is not balance.
Relationship is not interaction.
Innovation is not technological.
Culture is not optional.


This is not that

It seems that we have more opportunities to delete things than we realize.

Why is "Delete Facebook" even a thing, anyway? We suddenly realize this little chat window, status update thing... that it's bigger than we thought. It makes money, and it eats people's time. It gives us back something... Perhaps it's chewing up our time and spitting it back in our face. Maybe that's why we want to delete it.

Perhaps this is the way all infiltration occurs - not like a SWAT team storming in, but more like a slow insider spy force moving in one person at a time. This little toy of a website or app that at one point was pretty much just Farmville and poking becomes something more, quite stealthily at that.

So many things we use, though! So many that we don't even remember until we take direct and specific account. I have over fifty devices connecting to my router. Fifty. I remember clearly when my Internet was one-at-a-time - someone calling our home phone would "bump" me from my AIM chat sessions.

I deleted Slack from my phone and my computer for this reason - to subtract. A direct accounting of how my time is chewed up and spit back out at me, one emoji at a time.

"There's a person on the other side of that thing, you know." Yeah, of course there is. But my messages are chewing up their time just as quickly. The compression of that medium is more salient than ever.

When you fight over chat, you may be the only one seeing the fight, for example. Ever accidentally misread someone's tone through the frame of your computer screen, your phone screen? Ever make a mistake in an email because you were felt behind your computer?

I use <a href="https://freedom.to/">Freedom</a> and <a href="https://meetcircle.com/">Circle</a> to self moderate. I'm no special case, no elite soldier. I fall prey to this elaborate waste as well. And quickly, too. A snap of a command-T+twi... off to the races, I see the silliest thing under the Moments tab on Twitter and down the hole we go.

So I choose my barriers when I'm thinking clearly.

Coming down off the ledge means realizing that you don't have to do this. You don't have to sacrifice the only thing that binds us all: your limited time.

When you are thinking clearly and someone asks you, "would you like to have notifications that overwhelm you at any hour you are awake?" - few people would really want to opt-in to this. No one says, "man, I really hope I don't get much sleep tonight because I was staring at a screen too late." 

When I ask you about your life's ambition, you wouldn't say "to spend 12 hours on a screen every day keeping up with the latest gossip and news and hijinks to pacify my awareness of my limited existence." That's an uncomfortable, commonplace reality.

We think access is equivalent to convenience. We think access is actually a one-way street, too. That <em>we</em> have access <em>to all the things we use - all the information we want.</em> Every review of every restaurant so we find the BEST coffee at the perfect time of day, roasted seconds before we walk in the door so our majestic entrance is met with perfectly timed personalized service. I can hear the trumpets sounding now - a welcome to our kingly appearance of perfected modernism.

Oh, and don't forget just how important that coffee is to your personal mission to save the world. And you're going to do it, just as soon as you send this Tweet, check that email, and fire off a quick Slack message.

Come down. Come down off the ledge. You don't have to do this.

 But, as our friend <a href="https://en.wikipedia.org/wiki/Marshall_McLuhan">Marshall McLuhan</a> (or <a href="https://quoteinvestigator.com/2016/06/26/shape/">someone</a>) once said, "We shape our tools, and thereafter our tools shape us."

We have access to our tools, but they also have access to us. We have access to Facebook, to Slack. To iMessages and email. We have access to every TV show, virtually every book we can imagine, every piece of media. We can tour the world through our screens, leaving our bodies in the dust to rot in their inactivity.

We have all of this access, and believe we are observers, travelers, impacting only. And yet, the opposite is true.

We allow our email to have access to us. We allow our screens to impede on our ability to see clearly. We let our endless pursuit of the perfect coffee to eliminate serendipity. Our thirst for modernity and connectedness leaves us terribly alone, docile. Our time chewed up, our "deleting" becoming an act of valor.

Come down off the ledge. You don't have to do this. You don't have to give everything access to you. You can be whole, and you can leave all of that behind. You choose where your time goes - you choose who gets your attention. You choose, with your rational mind, how many steps to take in a day. You choose to create over consume.

But first, you have to come down off the ledge.

Stop believing that this is the inevitable way.

Stop pouring your time into endless buckets of nothingness, giving away your passions in exchange for pacification. Stop trading your sanity and your soul for safety and satiation.

The ledge feels safe, doesn't it? Jumping into the water, off the bridge like everyone else. It feels safe, because it's common - it's the way everyone else is going. We've come so far to not learn this lesson - that the crowd is a terrible thing to follow.

Come down off the ledge.


Come Down Off the Ledge

In my time as a developer and leader of other developers, I've focused a lot of my effort on understanding how people diagnose and solve problems.

This is an extremely broad topic, obviously, but still some interesting things have emerged as a fruit of my intrigue.

Here's an incomplete list of things that make problems... well, problematic, for humans.

- Mixing up recognition with diagnosis
- Confusing symptoms for roots
- Trusting narrative over facts
- Strict dichotomization
- Visible focus
- Control fallacy
- Tunnel vision
- Hindsight narratives
- Irrational, but popular, beliefs

Each of these is hard to see if you're in the middle of it. Extremely hard to predict. Easier to see in others, but also elusive because none of these problems presents itself perfectly.

Unfortunately this post won't give you a silver bullet, but here's a few things to try.

<ul>
<li><strong>Pair awareness with humility.</strong> Know that these things exist, and that you are vulnerable to them because you are human.</li>
<li><strong>Seek truth, not victory.</strong> Truth is it's own real victory - the efficient and rational victory, different from a perception-only kind of vanity-victory.</li>
<li><strong>Don't despise questions.</strong> Questions are often uncomfortable, difficult to answer, and may even seem like a waste of time. They are not. Generate more questions than answers.</li>
<li><strong>Always remember the dark matter.</strong> We see very little of what's going on at any point in time. Most of the time, our perception is less than the tip of the iceberg. Be happy and quick to blame randomness for a significant portion, if not all, of your successes <em>and</em> your failures, and then see if you can draw out similarities after you've accepted the role of the dark matter.</li>
<li><strong>Fight echo chambers by making more relationships and seeking wider experiences.</strong> Typical routines and limited relationships will keep your mind in one lane. Get into another lane. Try new things, meet new people, read new books, take a new way home. Allow randomness and serendipity into your life; not because those relationships must materialize into new opportunities, but because your brain is healthier with the variety.</li>
<li><strong>Separate analysis from sense-making.</strong> We crave sense-making. We instinctively search for causes to avoid future threats and compare our own situations against a good or bad outcome. In order to keep analysis and sense-making separate, use frameworks and cross-checking for analysis that doesn't produce a "narrative." (Don't forget dark matter: there may be no sense to be made.)</li>
<li><strong>Beware of certainty.</strong> Notice I didn't say "beware of confidence." You can be confident, and still uncertain. You can also act in bravery. But certainty is often a sign of turning something that is gray into something that is black or white; this kind of dichotomization, when done many times over, can generate a lot of error.</li>
<li><strong>Meditate on the fact that good people fail often.</strong> We don't read failure stories often enough to realize just how common they are. Very few mediocre stories make for good books, or documentaries. Remember that sometimes, despite all of your effort, failure or lackluster outcomes can still happen. Be thankful for them. If you don't choose to be thankful, you only hurt yourself.</li>
</ul>

This is a short list in a category where lists don't solve the problem. However, if you're reading this right now, I hope you leave this page encouraged and equally humbled at the reality of the complexity of problems we face every day. Give yourself, and others, grace. When you feel like you've done that, double it. We all need more grace.


The Problems We Have With Problems

The last two episodes of Developer Tea haven't shown any downloads, so naturally I reached out to Simplecast to get an answer.

While waiting, I kept trying to diagnose the feed directly, having totally forgotten that the RSS feed itself was being managed by Feedburner.

Unfortunately, Feedburner has a limit to the size of feed it will parse - specifically 1024K.

Luckily, Apple has made managing podcasts easy; updating an RSS feed is as simple as entering it into a field in the Podcasts Connect interface. Goodbye, Feedburner.


Podcast Feed Limited by Feedburner

Ever wanted to run some kind of one-off thing without pushing up a rake task? I came across this today and needed to clear out some database records. This works wonderfully:

```
heroku run:detached rails runner 'SomeModel.long_running_method' -r heroku
```


Running Long One-Off Rails Console Commands Detached on Heroku

I just got over what we are pretty sure was the [norovirus](https://www.cdc.gov/norovirus/). No vulgarity necessary - I slept in the bathroom one night, and basically forgot what day it was.

It felt crazy. Odd to me that sickness like this sweeps across the nation regularly, by the way.

Interesting thing about the norovirus - or maybe not interesting, but a fact nonetheless - it's incredibly *contagious*.

As in, even after you're good and before you ever have symptoms, you could be carrying the norovirus.

Of course it's not super serious if you're not a tiny child or an elderly adult. It's a bit more serious in our household since Lauren is pregnant.

(That doesn't mean it's tame, by any means... It was quite violent and very unpleasant, and a few days later my stomach still isn't back to 100% strength even though all the symptoms are gone.)

As a result, we started being extremely careful around the house. She's washed her hands upwards of 160 times since I got the virus. I've done the same.

You know, we use this word, *contagious*, to describe viruses all the time... the idea that one thing can be "caught" from the simple interactions - the mundane things we do with one another. Shaking hands, hugging, touching a doorknob. It's so simple, and yet that one action is literally what spreads that virus from one to two, and two to four, etcetera, until the [norovirus sweeps the United States](http://www.wsj.com/articles/the-stomach-bug-norovirus-rips-through-u-s-schools-1485191421).

I started thinking a lot about this phenomenon of contagiousness laying sick in bed.

_What else is contagious?_

Certainly we've used this word to describe "viral" media. But I don't want to talk about ways to succeed - I want to examine a cautionary perspective, in similar alarmed fashion to the Cutrell household bleaching extravaganza over the last few days.

I believe that in similar fashion to passing a disease, as a leader especially, _your words and actions are contagious._

Whether interfacing with a local competitor at the coffee shop, emailing with a client, or talking with a colleague - every interaction you have carries consequence, and more than you've expected in the past.

And when you recognize that your words are contagious, you'll also realize that when you are supporting a team, the virality of your attitude and messaging to that team is going to be painfully clear.

Those you lead will pick up on small things you say - small things you do. They will pick up on the linguistic ceremonies you promote and perpetuate around the office. They will pick up on your phone and texting and emailing habits. What's even more alarming is that - sticking with the metaphor here - the virus will mutate into something worse than you intended.

If you communicate slight negativity, it will likely expand in your team to full-blown negativity. If you communicate frustration with a client, you can generally expect your team will talk poorly of that client over lunch.

So, what does this mean?

It means that you, the leader - you have the job of knowing the impact of your words and your actions. You are contagious, and it's up to you what you spread.


Contagious


Liam,

You aren't here yet, and I'm not sure what your voice will sound like. But today is an important day in history.

There are a lot of words in our language that have no particular bend to them. "Important." "History." "Surprise." All of these words are, technically speaking, agnostic of "goodness" or "badness."

And today is an important day in history, where many people realized the result of a big surprise.

Last year, about a month after you were conceived, Donald Trump was elected president. Today was his inauguration. We saw the peaceful transition of power - watched the Obama family wave their final goodbye, and the signing of the first presidential orders by the 45th president.

This letter isn't here to steer you towards or away from liking Donald Trump; that's your decision, and ultimately you probably won't have much of an opinion about him for a long time.

Instead, I want to give you some words and thoughts to consider. By the time this president leaves office, you almost certainly will be between 4 and 8 years old. You will have heard his voice.

You will likely be affected by his presidency for years to come, perhaps for your whole life. You'll hear about him well beyond his term in office.

I'm not going to steer you towards or away from Donald Trump. I'm here to teach you about empathy. About perspective. To help you find a lens that views the world through what it could be, not what it is today.

A lof of the time, people in your country will use their own situation to make decisions. You will, too. We all do this - it's human instinct to protect ourselves, our families.

My bills, my taxes, my pain. My neighborhood, my city, my beliefs. My agenda, my family.

These are the things we value intrinsically, without being told we should, because we are trained by our own pain and pleasure. We want to be like our friends. Basic psychology says that being different from those we are in community with feels similar to pain.

This is no different from animals. Animals protect their own. They protect their space, their domain. It's survival.

But as we evolve - as we learn how to survive _better_, we also have a newfound sense of perspective and awareness. We learn about _empathy._ You may have heard this word before, but for the sake of this letter, we'll use the definition of "understanding and caring about the situations and perspectives of people other than yourself."

Empathy isn't something we stumble upon - it is something we practice. It's hard work.

Empathy gets really hard when you encounter someone you disagree with. Especially if those same people are those you care about. Perhaps the hardest people to practice empathy for, though, are those that you dislike, disagree with, who are very different from you in every way.

Liam, you have a perpetual license to agree AND disagree with me. And with anyone else you encounter. It's one of the fundamental parts of being human - your own path-finding.

My hope for you, Liam, is to remember that you are just as vulnerable as the next person to elevate your own concerns, survival, and pain above others. To elevate your beliefs. You may have the tendency to hold those beliefs over others' heads, even - imperialism certainly started somewhere.

But keep in mind, son - just because something goes well for you does not mean that thing is good for everyone. Just because your taxes decrease doesn't mean someone else isn't left out in the cold. Just because you are doing well, doesn't mean your neighbor is doing well.

When you get awarded the job, someone else is left unemployed.

When you win the game, the other team experiences loss.

When your country wins a war, there are always casualties.

Beyond these obvious realities, not everyone has the same experience. Not everyone is born into the same situation.

You, Liam, are extremely privileged. In this place in history, you have been born with the statistics skewed in your favor. Being a white male, for example, statistically makes you more likely to have earning power. Your mother and I will take care of you, and we work hard; you won't likely experience major poverty. You won't see significant violence in your neighborhood, and you will be around people who invest in your future and your welfare.

This isn't true for everyone. While everyone has equal rights, and everyone has technical opportunity based on legalities, not everyone will have access to those opportunities. Not everyone is willing to recognize those rights fully, and sometimes those rights are thwarted by the actions of others.

No system is perfect. The market isn't perfect, and neither are the suggestions for how to fix it. At this point in history, our income gap is large. Our national debt is insane. We have a lot of broken stuff laying around, and unfortunately just as with war, there are casualties.

You may have a friend one day who doesn't have the same privilege as you. You may work with people who are paid unequally to you. You may encounter someone who has experienced hate, or poverty, or violence, their entire lives. They may experience crippling debt as a result of medical problems. Perhaps they have a mental disposition that handicaps their employability. Or maybe they simply have a different belief system than you have.

Do not let anyone fool you: these people do not have the same life that you have, and treating them as if they do is nothing short of living a lie.

As a side note, many people do live this lie. Perhaps not intentionally, but rather because they don't think to confront these realities. Sometimes they are simply blinded by their culture. It's important to recognize that you, too, will have blind spots that you don't even realize. Always be humble and recognize this fallibility of your own perspective.

My prayer is that you don't ignore this disparity between you and those around you, and equally that you don't seek to coerce them into conforming to your way of life. Instead, I pray that you develop perspective, and breed empathy. To open your eyes and see people how Christ would see them, in the light of their suffering rather than in the light of your own survival and benefit.

Remember that empathy is a marker of maturity. Develop a worldview that takes into account the realities of others' experiences. To understand and work on behalf of others _as well as_ yourself.

I love you, son, and I believe you will keep your heart, mind, and eyes open to what is happening for your neighbor as much as for yourself.


Letter to Liam, Inauguration Day 2017

If you are getting into software development, my recommendation for 2017 is that you learn JavaScript (the ES6 variety).

Learn how to make a web service or two, and how to launch on a given domain; learn enough about HTTP and some kind of serving technology to get a service up and running. This will give you enough skills to be a junior developer somewhere long enough to build more valuable skills.

Next, I recommend you split your time between learning and pursuing these two things: user psychology-driven design and machine learning.

The psychology driven design learning should give you an intuition and method for learning what people want, and why.

If you want a long future in this field, machine learning and designing experiences around AI is your ticket to future value. Literally ALL of the biggest technology companies in the world are investing in this - it's not going anywhere any time soon.


What To Learn As a Brand New Developer in 2017

<p>Year twenty-eight has been, to say the least, eventful.</p>

<p>A few important highlights for those of you who like lists (myself included):</p>

<ul>
<li>Whiteboard grew by 7 new people - this is a huge responsibility</li>
<li>Developer Tea turned 1 year old (and hit numerous milestones)</li>
<li>I pursued and attained my private pilot license</li>
<li>Lauren and I became more involved at Harvest Chattanooga</li>
<li>Easily the most important thing: I found out I became a father, and will see my child in year 29</li>
</ul>

<p>Here's some trivial memory highlights:</p>

<ul>
<li>Dad and I started working on revitalizing N3244Y, his Cessna 182E, for the two of us to share and fly together. I'll be responsible for avionics, and dad for the mechanical side. We'll never be done working on this plane, but it will be in service this next year.</li>
<li>Lauren and I upped our house game this year: refinanced our loan, got some better furniture, and built out a new room upstairs (as fate would have it, before we knew we'd be having our child soon)</li>
<li>We bought our Subaru Outback this year</li>
<li>Whiteboard launched Home Movies this year, just in time for Thanksgiving rush. This is a huge accomplishment, and a long time coming; we've spent many hours watching home movies, and I can't wait to see my children side by side to my and Lauren's baby videos.</li>
<li>Both of our next door neighbors moved this year. It would be easy to assume it's something to do with us, but in fact, the neighborhood has appreciated significantly, enticing people to sell high.</li>
<li>Tons of other awesome stuff happened this year that I'll have to fill in as I remember it... Come back and you'll see the edits.</li>
</ul>

<h3>Odd Lessons from 28</h3>

<p>With all of the awesome stuff that has happened in year 28, the world around me seems to be in a strange, tense state.</p>

<p>This was easily the strangest political climate we've had in the U.S. since I was born. Of all the odd encounters with people I've had in my life, having a differing political opinion from another person creates one of the most palpable feelings of division that I've ever felt. I was out with my family in Dothan today. Coming out of a store, I saw a truck - and there is no exaggeration here - with the Christian flag, two Alabama "Roll Tide" flags, an American flag, a Trump flag, and I believe a confederate flag (although admittedly I was too dumbfounded to remember in perfect detail). And to be honest, it wasn't that I have extremely different ideals from this person. I am fiscally conservative (though not a Trump supporter), and I confess faith as a Christian. But with my beliefs and perspectives, I cannot imagine what level of commitment or passion about my own beliefs I would have to have to fly that many flags, no matter what is on the face of it.</p>

<p>This was kind of a meandering rant, but I suppose my point is this - in a world where opinions of those closest to you can more easily than ever be extremely different, remember that it's not your job to fly a flag, but instead to live amongst one another. This applies far less to the relationship between flag guy and me, and much more to my relationship with my own family members, friends, and colleagues who differ from me. Politically, culturally, even in taste - I'm learning that sharing my opinion is less valuable than learning the perspectives and opinions of <em>others</em>, and using that information to get closer and treat each other better. If you're close to me, I love you first and foremost, and want to give you the best version of me that I have.</p>

<p>The times I've shared my opinion out of anger, frustration, or a sense of righteousness, I end up being overly preachy. I wouldn't want to be around me in those moments. Conversely, when I share my opinion from a logical, critical perspective to better something, particularly in a professional setting, the opinion then holds value. But here's the catch: in every scenario that my opinion was valuable, it was explicitly asked for. Lesson learned: <strong>don't be quick to share an uninvited opinion</strong>.</p>

<h3>I am your father.</h3>

<p>I just watched Rogue One today. Quite good in my opinion. There are so many father references in Star Wars. Basically every movie has a pretty significant hinge on a father-son or father-daughter relationship. Some mother roles in there too.</p>

<p>I'm one of those. I'm a father. My own Dad looked at me tonight and said, "I can't believe you're going to be a Dad." And honestly, I can't either.</p>

<p>I usually am relatively composed, and I do a decent job interpolating basic advice for people who are well beyond my experience level, age, wisdom level, etcetera. However, when it comes to fatherhood, I am clueless. No experience, unless you're counting uncle years.</p>

<p>So, my plan is to be <em>good</em> to my child. Be present. Challenge them to love learning even more than I do. To look at life with wonder and positivity, and to create more of what ought to be. To teach them conviction, and the importance of caring for others, and what it means to work hard, and play hard. I want to teach them how to be kind and compassionate to others, and tolerant and respectful. I want to help them develop their own belief, and pray for them to learn what it means to have faith and hope in Christ. I will show them that I love their mom, and teach them to love family.</p>

<p>But honestly, I know I will mess some of that up. I know I will say the wrong things sometimes, and that there will be bugs in my system from day one.</p>

<p>I hate diapers, by the way. Absolutely terrible with that kind of stuff. It's not that I don't want to do the work.</p>

<p>I'd stay up all night and rock a crying baby if it meant avoiding diaper duty. It makes absolutely no sense.</p>

<p>I do love my child. And I hope I get most of the stuff right. Maybe one day, they will get a chance to read this, and see how much I thought of them.</p>

<p><em>I'm up at 3AM writing this blog, mostly to get a chance to write something for you to read, little one.</em></p>

<h3>The year that took so many celebrities.</h3>

<p>A great year for me, but we've seen so many celebrities go before their time. Everyone's complaining that 2016 is unusually bad, etc. I'm sure we've had a similar one before. Just Google it, no need to belabor the point. A good insight on a relevant reddit thread - perhaps it hits so hard because many of these folks were younger than average death age, and we are realizing the mortality of our own parents, and perhaps in turn our own mortality.</p>

<p>I have a penchant for finding reasons why I'm more healthy or less likely to die like that person did. Or, justify that they were really old, or somehow emotionally prepared to die, or that the statistics work more in my favor. Coping, or maybe valid reasoning, or a cocktail of both. Either way, it happens to us all at some point.</p>

<p>I hope when I'm gone, young or old, that those closest to me will adapt. I don't want my absence to be a handicap, but rather my memory to be an inspiration. The next 28 years, if I am blessed to have it, I want to spend loving my wife, my children, my family, and those around me enough that every day could be my last, and I'd know I left it all out here and took no love to the grave.</p>

<p>A strangely dark turn to a birthday post. Let's back out of this little black hole.</p>

<h3>29</h3>

<p>The 29th year begins at 7:30 tonight.</p>

<p>It's not scientifically important, by the way - unless there's some weird moon rhythm thing I don't understand. It's a step marker - a measuring stick. So we don't lose our place.</p>

<p>For year 29, I don't want to ignore that measuring stick one single day. Every day, I want to walk away from more thankful than the last.</p>

<p>Concrete goals:</p>

<ul>
<li>Create a habit of writing more often. Here on WordPress. In this nicely made but incredibly generic 2017 theme. A big hurdle before was that I was stuck on the tool rather than the practice.</li>
<li>Get my IR ticket. Instrument flying will help inform me how to be a safer pilot.</li>
<li>Get into the thousand club. This was a goal last year that I didn't pursue correctly. Ended up hurting my back. Gonna try again this year.</li>
<li>Read more books. I am ashamed to say that though I read quite a lot last year, I read mostly digital things. Shorter pieces. I want to read more this year - perhaps a book a month is a solid reachable goal.</li>
<li>Be active more days than not. This goal is important to me - I feel better and function better when I am active at least 4 days out of 7.</li>
</ul>

<h3>Conclusion / TLDR;</h3>

<p>This year was awesome. Did some super cool stuff. Some crazy things happened in politics and celebrity land. I'm gonna be a Dad, and I want to be a better person both before and after the Baby arrives.</p>


Twenty-Eight Years


There's a moment of &mdash; let's call it "reckless abandon", or as <em>Ex Machina</em> refers to it, a Pollock-ian moment of disregard or entropy or untargeted action &mdash; the moment where we say "I'm not sure if this step is perfect or calculated quite correctly, but I'm going to invest a little bit more than just thought."

That moment seems to be such an important catalyst, and I don't fully know why, but I have a guess.

I think that we have a very hard time as humans understanding our potential and our ability to accomplish things in the world until we accomplish the smallest part.

In the same way that water seems terrifying until you swim for the first time as a child, and in the same way that programming seems intimidating to those who have never been exposed to a single line of code - in the same way, anything we have on our list of "what I'd like to do with my life" can seem distant until we take the first step.

It's not a hack. It's just some basic psychology. Once something is quantified, it is no longer nearly as mysterious.

So - what exactly, specifically, and concretely, are you doing to accomplish the thing you want to accomplish? Are you acting, or are you thinking?

Think of it as a type of a meditation. When you simply sit in deep thought (NOT meditation), you lose sight of the reality of your goals much more easily. But, if you instead act in the world with slightly less value placed on intention and a bit more value placed on action, you'll be surprised by what anchors you begin to drop into the ground, and how much easier it will become to imagine your aspirations, finally, as achievable.


Small Anchors Make a Big Difference

Last month, I had the opportunity to speak at the Chattanooga Developer's lunch. I talked about how to be a great beginner. This talk isn't just for beginners, though - it's for anyone who is working in technology, or any industry that requires constant skill acquisition.

https://youtu.be/gZiiKvoLLwU


How to Be a Great Beginner (Talk)


I've been using the metaphor of blacksmith and cobbler recently in discussions about craftsmanship. Why?

Blacksmiths and cobblers are renowned as dedicated to their craft. Repeating the motions every day. They both take raw materials, perform a process of actions using a set of tools to refine those materials, and consistently produce something of practical value that is ready to use. For blacksmiths, the tools and materials are quite different from the cobbler's, but they share a lot of the same fundamental disciplines in practice.

With a little bit of Google research, you can find that a blacksmith today uses basically the same tools as blacksmiths before the industrial revolution, and those tools went largely unchanged for centuries. Of course, the Industrial Revolution changed our reliance on the local blacksmith, but the toolset of any blacksmith of any period would be quite similar to any blacksmith from any other period.

Similarly, the cobbler's tools have remained relatively unchanged. When new tools have come into the scene, they come by absolute necessity. The blacksmith and the cobbler wouldn't spend all of their time searching out new tools, constantly on the lookout for something to bend iron in a new way. More likely, the blacksmith would always be on the lookout for great scrap iron, and the cobbler on the lookout for good deals on leather, or building relationships with the people who fashion the cloth and buy the boots he makes.

<h2>We have a tooling problem.</h2>
Notice that neither the blacksmith nor the cobbler are careless about their tools. Both of them are highly focused, and highly skilled with their tools, and actually rely quite heavily on them. Their jobs depend on having a reliable toolset that they are experts at using.

I think developers today have a fundamental problem with tooling, and it's simple: <strong>we are constantly shopping for new tools.</strong>

You might be thinking, "I'm not shopping - these tools are free!"

But that's not totally true. Certainly, free and open-source projects don't cost you the currency available in your bank account. But they cost you another, perhaps more valuable, currency: time. You spend time looking, adopting, and deprecating your tools. You spend time reading blogs and books that compare tools, just for the sake of picking one. You spend time switching your code from one set of tools to another. You spend time retraining muscle memory, sometimes to accomplish the same goals.

<h3>Admission: this analogy isn't perfect.</h3>
Of course, we have a different trade from blacksmiths and cobblers. Our trade requires that we do, at a much faster pace, adapt our toolset to new demands in our industry. And perhaps it's because the product we make is virtual, not physical - the materials we use are thoughts, not iron and leather. And, it's also important to know that picking the right tools absolutely has an undeniable value proposition for your work. But the underlying truth is this: our constant shopping for new tools costs us that precious currency of time. The time you spend browsing the endless aisles of new programming libraries is time that could be spent becoming an expert craftsman, learning your existing toolset inside out.

I know, it's a hard problem to solve. I know, it seems like not knowing about a particular tool or another might put you behind the ball. So I'm going to make a very clear distinction here:

<strong>I'm not saying to bury your head in the sand, and never investigate new tools.</strong> Some very smart, influential programmers recommend learning a new language every year. I don't disagree; this keeps your brain sharp, and helps you stay aware in a constantly changing landscape. What I am saying is this: if you are constantly trying to <em>master</em> something new, you'll never master anything. Instead, you should be consistently <em>aware</em> of new things, while focusing on mastering <em>few</em> things.

<h2>When to pick tools: 6 guidelines</h2>
<em>Note: this is not a cohesive list of the only times you should pick tools, but it should give you some idea of how to think.</em>

- When you've got a problem that is proveably unsolvable or otherwise extremely inefficient to solve with current tools, especially if that problem has already been solved elsewhere. (If you're a C programmer and you need to serve a webpage, it's probably a good idea to learn about an existing tool like Apache instead of rewriting a web server in C.)
- When switching provides undeniable and exponential long-term gains. For example, switching to a new text editor that will increase your productivity every moment you are using it (I did this recently by moving to vim).
- When the tool is an easy win. Pick tools that are easy to adopt and provide obvious value without much investment.
- Lest we be hacked, upgrade your tools when there are security vulnerabilities in that tool.
- If You rely on your tool having adequate support or community involvement, it might be a good idea to choose a new tool when an old tool's support or community become dormant. With that said, choose based on your values in the first place. If the community is an extremely important value to you in the long run, only choose to invest time into tools that have a thriving, vibrant, and committed community.
- When the tool stacks well on your existing toolset. For example, if you have already learned HTML and CSS, it's probably a good idea to learn JavaScript, as the gains you receive by learning JavaScript are naturally complemented and increased by your knowledge of HTML and CSS. Other stacks you could learn:

  - You know Assembler? Learn C.
  - You know PHP? Learn Laravel.
  - You know LISP? Try out emacs.
  - You know Ruby? Learn about Rack or mruby.
  - You know Objective-C? Look into Swift.
  - You know JavaScript? Learn about how Node/IO.js works.
  - You know Java? Learn about virtualization, or learn Scala.
  - You know Apache? Learn some Linux sysadmin basics.

Pro tip: Be certain that you differentiate your <em>learning</em> efforts from your <em>tool-picking</em> efforts. You might choose to learn a new language that doesn't stack well with your current toolset, just to expand your brain's ability to adapt and think in new patterns. This has value, even if you never use that language as an actual tool. This is the whole idea of <a href="https://developertea.com/episodes/6877">code kata</a>.

<h2>5 step guide to picking tools</h2>

1. Look at your materials (read: consumer devices, browsers, iOS APIs, your unique service offering, etc)
1. Look at the available toolset (languages, frameworks, hardware, outsourced efforts)
1. Imagine your product (you fill in the parentheses on this one)
1. Pick the tools that can turn your materials into your product (make your best educated guess)
1. Repeat every 2-3 years, keeping a majority of the tools you picked previously, and dropping only the ones that didn't work so well.

<h2>Conclusion</h2>
You use your toolset every day; it's natural to want to refine that toolset. But changing your toolset constantly might mean that instead of spending time becoming a craftsman, you are just wasting your time constantly tool shopping. Learn to say no when your tools are perfectly capable of doing the job you need for them to do, and learn how to properly adopt new tools when the time and situation are right.


The Infinite Toolset, Craftsmanship, and Developer Sanity


I recently did a talk on some of the concepts in the book I'm working on. The talk really helped clarify some of the ideas I want to share with the world, and I'm sharing that talk with you today. Specifically, I discuss why our perception of creativity as it relates to logic is wrongly constructed, and a better way to understand our differences.

Hope you enjoy!

<div class='iframe-holder' style={{"position": "relative", "width": "100%", "height": 0, "padding-bottom": "56.25%"}}>
<iframe src="//www.youtube.com/embed/EooBGZpsE_Y" frameborder="0" allowfullscreen style={{"position": "absolute", "top": 0, "left": 0, "height": "100%", "width": "100%"}} /></div>


Talk: Creative DNA

Dustin Curtis wrote a <a href="http://dcurt.is/voice-interfaces">fantastic article</a> discussing the shortcomings of voice interfaces. I'd like to discuss a few further points in relation to this problem.

Go read his thoughts first, then come back. I'll wait.


<h3>Contextual Awareness</h3>
Dustin outlines that a lack of contextual awareness makes voice interfaces less than simple to use. I'd argue that this contextual awareness goes beyond voice interfaces and software, and affects the full product and experience design. At the end of Dustin's article, he tells people to imagine what could be done; here are a few ideas I have about contextual awareness as it relates to our devices today.


<h4>Why do I have to tell my phone when I'm holding it with one hand?</h4>
The Freaking Huge iPhone 6 Plus and the Slightly Less Huge iPhone 6 bring to light some important contextual issues related to human factors. Specifically for those who have smaller hands (most applicably, women), using the phone with one hand becomes difficult. In fact, Apple has introduced a strange accessibility mode that brings the top of the screen down by hitting the home button a few times in a row.

That's nice of them to help out, but why do I have to tell my phone how to be accessible every time I use it? Personalized accessibility should come as a standard. It shouldn't be that difficult of a task. In fact, how cool would it be if I could tell my phone how well I could reach, and it remember that? Perhaps adapt my interface to work with my hand better. Or maybe track where my thumb is and move the icons nearer to it, magnet-style. Seems relatively doable if Amazon's phone can track my eyes.

This kind of context is the low-hanging fruit; the things that continuously provide a positive return in user experience. This is the evolution of "user account preferences".


<h4>My life has modes; why doesn't my computer?</h4>
If you are like me, you have different modes of being. While I'm at work, I'm in work mode. Not everyone treats this issue in the same way, but perhaps you've experienced this before. This is especially important for people who use their computers in multiple contexts. I'd like to have a "mode" switcher on my computer. I should be able to flip a switch and open an environment on my computer that helps me focus, relax, or accomplish a specific set of tasks. For example, to record a screencast, I need my desktop cleared, a specific wallpaper set, a particular resolution on my screen, Do Not Disturb turned on, and an array of programs opened.

This should be a contextual setup on my computer, but it's not.

Maybe you have kids that you want to allow to use your computer, but you don't want to set up full user accounts for them. Why can't you easily set access control and flip a switch to change contexts?

It's very simple to make this happen - in fact, on a few occasions, I have set up scripts to make these kinds of contexts happen with a simple command. But unfortunately, my operating system doesn't do this on its own, and my contexts shift over time. Thus, maintaining scripts to handle this for me is unrealistic.


<h4>Mobile isn't replacing my laptop any time soon - it's just expanding it at a different resolution.</h4>
It seems that our desktop/laptop computers are staying relatively stagnant. The atmosphere of operating systems have changed in our lives because of mobile, but the desktop isn't keeping up. My computer should have sense-abilities that are currently reserved only for my phone, or at the very least it should be tightly connected with my mobile devices and use the sensors in my phone to inform it of context. My health tracking should be <em>most accessible</em> on my laptop, and should change in resolution as I move from the larger and more flexible laptop to more limited devices.

My laptop should be as smart or smarter than my mobile device. Until the resolution of interaction on a phone matches or surpasses that of the interaction on a desktop computer, desktop OS innovation <em>must</em> keep up.


Re: Voice Interfaces


<h2>I want you to steal my ideas.</h2>

I've said it before, and nothing has changed. Ideas are important, but they aren't proprietary. I want these things to exist, so hopefully with this post I can inspire someone to make them, even if that person is me.

The iWatch (or whatever it is going to be called) is announced this week, and that's exciting for entrepreneurs and developers for a lot of reasons. The ideas I present below are sort of like predictions; because I don't know the features of the watch, I'm making a lot of assumptions.

As always, the ideas presented below are in no way my property. Think of them as money left on the sidewalk. In an envelope labeled "take me!". The only thing I ask is that you <a href="/lets-talk">contact me by emailing me</a> or reach out to me on Twitter (<a href="http://twitter.com/jcutrell">@JCutrell</a>).

<h3>1. Viral Crowdsourced Fashion</h3>
Very simple: allow people to make watch faces and share them. Make them available like a YouTube video. This idea is as old as desktop backgrounds, but it has a brand new twist: fashion.

<strong>Why I think it will work:</strong> Fashion is obviously a part of our lives. However, technology and fashion have not fused completely yet. The only company truly bridging the gap between personal technology and fashion is - you guessed it - Apple. Apple's products provide social status and expression of "personality." The iWatch will have own a large part of this market, and will mark the true fusion of technology and fashion.

<strong>Bonus points:</strong> Make the faces sellable and take a small commission. (Not sure how this would work with in-app purchases, but that's where you can get creative, right?)

<h3>2. Access-oriented Applications</h3>
Everyone is talking about the mobile payment industry as a game changer for the iWatch, but let's back up for a second and talk about the fundamental difference in payment from your watch versus from your wallet.

Wallets are no more "mobile" than watches. The cognitive change the iWatch introduces is a new sense of <em>access</em>. And along with that comes a new category in application development that hasn't really taken off with mobile phones.

This is my personal theory, but I think the cause for the failure of mobile device access applications (case in point, Passbook) is at least partially due to the disconnect from the phone as directly connected to you at all times. With a wallet, it works partially because we were born into it (our parents did it), and also simply because we had the previous understanding of carrying cash.

With a watch, we have a newfound freedom to directly identify the watch with the wearer. I wouldn't be surprised if the payment apps didn't eventually take bio signs into account for fraud protection.

For these and many other reasons, it's time to take these apps a step further. It's time to start using the bio-connectedness that these devices will provide us with to grant access to restricted places requiring identity. This goes from more secure login services and better/more accurate TSA screenings, to check-ins and social physical presence applications.

<h3>3. Quantification, Meet The Informed Self</h3>

The iWatch will most likely mainstream the quantified self movement. We've seen this getting a large part of the media attention.

But for those getting into the game now, it's time to start thinking past our current place in the quantified movement, and towards the next step. I'm making a prediction: that next step will be to make sense of the data.

Anyone who has worked with infographics for long will tell you that the single most important part of their job is finding and choosing the best metrics and clearest visualizations of those metrics. There is some science to this, but there's also some <em>gut</em>.

What does this mean? It means that our quantifications don't really provide us with anything other than raw data, regardless of how pretty it is. We need to take this raw data and turn it into something meaningful. Look at strong correlations, and suggest potential causation. Compare seemingly unrelated things, like lines of code versus number of steps walked per day. Give users a framework for making decisions, and then comes the fun part: using <em>big data</em> to come to conclusions about trending correlations in day-to-day behaviors of the population.

But the first step is to take the quantifiable numbers and show some kind of derived qualitative information.

<h3>4. The ultimate timer</h3>
Seriously, we're still making time tracking applications? Yes. Because all of them suck. Well, maybe they don't suck, but I haven't found one that is natural. I end up watching a clock. Or my watch.

<strong>Aha!</strong>

A unique opportunity for productivity apps related to time: use the watch paradigm. This one seems obvious, but whoever wins this one will win big.

I'm thinking something like setting up a few behaviors that the watch can sense and infer with, but then make it very simple - tap, swipe to client, tap again to start timer, tap again to stop timer. On my watch, not my phone. Certainly not on my computer. I use my computer to create invoices. I use my timekeeper to time things.

<h3>Conclusion</h3>
The iWatch presents a lot more opportunities than I've even discussed here. I'd love to hear what you think about these ideas, and I'd love for you to share yours with me. Or, by all means, feel free to take mine and build it.

Hit me on <a href="http://twitter.com/jcutrell">twitter (@jcutrell)</a> if you want to continue this conversation.


Steal these iWatch App Ideas


<p>I, like many developers and tech consultants, am a chronic underestimator. When I make an estimate, I do so believing that the estimate encompasses the effort necessary for me to accomplish each and every goal for that project.</p>

<p>And I’m wrong, nearly every time.</p>

<p><img src="http://imgs.xkcd.com/comics/estimation.png"></img></p>

<p>People have a completely skewed perception of time. Checkout this excerpt from a Huffington Post <a href="http://www.huffingtonpost.com/jon-hotchkiss/how-bad-is-our-perception_b_3955696.html">article from last year</a>.</p>

<blockquote className="large">
  <div class="inner">
    <p>This vs That’s initial research is in line with previous research into time estimation, which has revealed that our ability to accurately estimate time is influenced by our emotional state, how hungry we are, how tired we are, whether our eyes are open or closed, what we are doing, among many other factors.</p>
  </div>
</blockquote>

<p>Aside from the fact that people in general are terrible time estimators, it’s also my opinion that estimating a multi-stage project all at once is about as useful as guessing who will win March Madness at the beginning of the bracket. It’s not a good idea to put your money on that bet.</p>

<p>Here’s one of the biggest reasons why we estimate improperly.</p>

<h2>Our perception of effort and knowledge are different from our perception of implementation.</h2>

<p>How long would it take you to make 100 sandwiches?</p>

<p>How easy is it to make a sandwich? Certainly not all that hard. You’ve done it a million times, so it’s not too difficult. Five minutes on a good day, 10 minutes tops.</p>

<p>So, how long does it take to make 100 sandwiches?</p>

<p>I asked my wife this question, and she estimated an hour and a half. Seems fair to me - probably about what I would have guessed as well.</p>

<p>Would you immediately think to guess that it would take 500 minutes (8.3 hours)? You probably think that you’d have a system - a way of solving common problems over and over by that point. 100 sandwiches shouldn’t take nearly 8 hours, considering how easy sandwich-making is. You’d have a killer sandwich assembly line.</p>

<p>But even if your amazing sandwich assembly line was world class and doubled your efficiency from 5 minutes to 2.5 minutes, you’re still going to finish sandwich 100 at the 250-minute mark.</p>

<p>This is the cognitive problem we face in estimating time for development. We see projects that we have the technical ability to solve without having to acquire any new knowledge, and therefore we have a tendency to underestimate. Things we already know how to do and systems we fully understand seem like they should take much less time to implement than they actually take.</p>

<p>Stop thinking about how easy a project is, and start thinking about how long it takes you to make one sandwich.</p>

<p><img src="http://37.media.tumblr.com/42320ccdaf3a99dc2c4257752ae975c7/tumblr_mpxo0kExi61rom85wo1_500.gif" alt=""></img></p>


Why Developers Underestimate: One Reason That Will Change the Way You See Projects Forever


<p>Trying to serve your Parse files via SSL/HTTPS? You’ll notice that you can’t force it, and Parse doesn’t support this via their file URL scheme. But you can use the same trick Parse uses on <a href="http://www.anypic.org/">Anypic</a>.</p>

<p>Replace <code>http://</code> with <code>https://s3.amazonaws.com/</code>.</p>

<p>So if you start with this:</p>

`http://files.parsetfss.com/b05e3211-bf8b-.../tfss-fa825f28-e541-...-jpg`

<p>The final url will look something like this:</p>

`https://s3.amazonaws.com/files.parsetfss.com/b05e3211-bf8b-.../tfss-fa825f28-e541-...-jpg`

<p>In ruby, that’s:</p>

`url.gsub "http://", "https://s3.amazonaws.com/"`

<p>In JavaScript:</p>

```
var url = // your url...
var subbedUrl = url.replace("http://", "https://s3.amazonaws.com/");
```

<p>Boom - fully secure Parse files.</p>


Quick Tip: Serve Parse Files via HTTPS

<p><a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;text=I%27m%20learning%20about%20%22The%20Path%20to%20Productivity%3A%207%20Hacks%2C%20Principles%2C%20and%20Patterns%2C%20from%20@jcutrell&amp;hashtags=%23productivity%20%23hacking&amp;">Share this article on Twitter</a></p>

<p>Productivity is such a huge focus in our lives. We are all allocated the same amount of time, so how do some people do amazing things while others always seem behind the curve?</p>

<p>The answer, in some ways, is that those who are on their game have learned how they themselves can be <em>productive</em>. Certainly there’s no one shot solution, and productivity isn’t the only answer to rising above average, but I would argue that those who <em>are</em> above average absolutely cannot ignore the importance of finding ways to stay productive with their time.</p>

<p>In this article, I will discuss my tips for finding personal productivity.</p>

<h1>1. Start Treating Time as a Precious Resource</h1>

<p>Time is your most valuable resource. It is the resource that no one can leverage against another person, because we are all given the same amount of time in a given day. The only way we can rise above average is to treat time for what it is: a consistently valuable and rare resource. Truly adopting this perspective is the driving informer behind changing your habits. This is your motivation.</p>

<p><a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;via=jcutrell&amp;text=%22Start%20Treating%20Time%20as%20a%20Precious%20Resource.%22%20-%20The%20Path%20to%20Productivity&amp;hashtags=%23productivity%20%23hacking&amp;">Share this tip</a></p>

<h1>2. Find Your Time</h1>

<p>What is Your Time? This isn’t a metaphorical or philosophical question - it is actually quite practical. What time are you giving yourself per day? Mine is from 6 to 8 in the morning. This is a new habit I am constantly forming, but this is when I build my side ventures, when I do my reading and writing, whatever I choose to do. Specifically, my time is uninterrupted, and I can gain pure focus during that time. I’d recommend mornings, as this is the time when you are most likely to have the drive necessary to turn that time into value.</p>

<p>Give yourself the incredible gift of time. No one else can give it to you.</p>

<p>Pro tip: The morning is also a good option because we often sleep as a luxury. Do you prefer the luxury of sleep, or the reward of accomplishing your goals? I know my answer.</p>

<p><a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;via=jcutrell&amp;text=%22Find%20Your%20Time.%22%20-%20The%20Path%20to%20Productivity&amp;hashtags=%23productivity%20%23hacking">Share this tip</a></p>

<h1>3. Don’t Trade Your Time Cheaply</h1>

<p>When I was doing my masters program, I constantly had to make a choice: order food in, or go and get lunch. (This was before my wife and I made a conscious decision to eat as many whole foods as possible.) While the delivery fee was outrageous sometimes, I had to consider the value of my time, and on many occasions, the delivery fee was justified because ultimately my time was worth more than the hours I would spend traveling and sitting. What are you trading your time for? Could you delegate or hire out a task you are currently spending your time doing? Something even as simple as mowing your lawn could be hired out, freeing you up for more time to spend doing things only <em>you</em> can do.</p>

<p><em>Note: I do not recommend take-out food as a time saver (or restaurant food in general) unless it’s an absolute necessity; eat a load of plant-based whole foods, and keep them fresh in your fridge and pantry available at all times. This will likely save you money in the long run anyway, even if you go Gung ho organic like I did.</em></p>

<p><a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;via=jcutrell&amp;text=%22Find%20Your%20Time.%22%20-%20The%20Path%20to%20Productivity&amp;hashtags=%23productivity%20%23hacking">Share this tip</a></p>

<h1>4. Make Your “Must Do Today” List, TODAY.</h1>

<p>Unlike your regular to-do list, which can grow to extraordinary lengths, create a list with non-negotiable tasks that you must finish today. Make that list accomplishable, and prioritize by the value that is delivered both now and in the long term.</p>

<p><a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;via=jcutrell&amp;text=%22Make%20Your%20%27Must%20Do%20Today%27%20List%2C%20TODAY%22%20-&amp;hashtags=%23productivity%20%23hacking&amp;">Share this tip</a></p>

<h1>5. Put Productive Time Before Reactive Time</h1>

<p>Don’t check your email, your phone, or your chat messages until you mark off the things on your must do today list. Other people have “must do today” lists, and if you’re not careful, you’ll work harder on their list than you will yours.</p>

<p>Productive time means time that <em>you</em> have control and domain over. It’s time that you spend working towards your goals. Reactive time is time that someone else is spending for you. This isn’t just “side job versus work” - this is totally applicable at your day job. Want to get your task list done? Do it first - make it a priority. You’ll be surprised how a few hours often doesn’t make a bit of a difference for those people who are fighting for your time and attention, but how HUGE of a difference it makes for you.</p>

<p><a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;via=jcutrell&amp;text=%22Put%20Productive%20Time%20Before%20Reactive%20Time%22%20-%207%20Productivity%20Tips&amp;hashtags=%23productivity%20%23hacking">Share this tip</a></p>

<h1>6. Limit Yourself</h1>

<p>Having a tough time leveraging your hours properly? Work 2 hours less per day for a week, but retain the size of your Must Do Today list. I bet you will be surprised at how much more you will achieve when you set a concrete end-time. This principle isn’t new, but it certainly is effective, and worth echoing again here.</p>

<p><a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;via=jcutrell&amp;text=%22Limit%20Yourself%22%20-%207%20Productivity%20Tips&amp;hashtags=%23productivity%20%23hacking">Share this tip</a></p>

<h1>7. Decide How You Should Spend Your Weeks</h1>

<p>Michael Hyatt has a fantastic resource that helps you with this particular effort, which you can find <a href="http://michaelhyatt.com/how-to-better-control-your-time-by-designing-your-ideal-week.html">here</a>, but the basic idea is this: If you don’t have a plan for how you want to spend your time, how can you expect to accomplish your goals? As Michael says, take the initiative to “live on-purpose.”</p>

<p>Take the time to evaluate your habits and values, and what you want your weeks to look like in a perfect world. Set your long term goals, and design your ideal week around what it would take to achieve those goals, realistically. If you are lucky enough, you are the author of your own time. Even if you work long hours at your day-job, you are the author of your off-time. Evaluate and consciously determine how you want to spend it.</p>

<p>This exercise does a lot for you. It might even give you a good perspective on what things need to be pushed off your plate indefinitely, or maybe it will help you realize that you are already crazy productive.</p>

<p><a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;via=jcutrell&amp;text=%22If%20you%20don%27t%20have%20a%20plan%20for%20how%20you%20want%20to%20spend%20your%20time%2C%20how%20can%20you%20expect%20to%20accomplish%20your%20goals%3F%22&amp;hashtags=%23productivity%20%23hacking&amp;">Share this tip</a></p>

<h1>Conclusion</h1>

<p>This is by no means an exhaustive list, but hopefully you will find a few of these things helpful in your own life. If you do, <a href="https://twitter.com/intent/tweet?url=jonathancutrell.com%2Fthe-path-to-productivity-hacks-principles-and-patterns&amp;text=I%27m%20learning%20about%20%22The%20Path%20to%20Productivity%3A%20Hacks%2C%20Principles%2C%20and%20Patterns%2C%20Part%201%22%20from%20@jcutrell&amp;hashtags=productivity%20%23hacking&amp;">Tweet about it</a>!</p>


The Path to Productivity: 7 Hacks, Principles, and Patterns

_Update: Looks like Wunderlist was bought by Microsoft, so maybe take this all with a grain of salt._

<p>I’m loving the newest version of Wunderlist. Honestly, I’m not even sure what all has changed, but here’s what I know: Wunderlist is probably my favorite ToDo management application thus far.</p>

<p>That’s a big deal, you know… there’s about a thousand ToDo managers.</p>

<p>Here’s how I’m using it.</p>

<h2>1. Put it everywhere</h2>

<p>One of Wunderlist’s primary killer features is the fact that it is available everywhere. Native apps for Apple devices, and a web interface. It really is everywhere.</p>

<p>So make your to-dos accessible everywhere. Unlike your email, having your todos accessible actually <em>helps</em> your productivity if you know when to look at the list.</p>

<h2>3. Use Tags to Sort by Energy/Time Required and Context</h2>

<p>Who knew you could do hashtags in Wunderlist. This allows for clickable searchability. Adding some kind of context allows you to do things like: “Clean out closet. #15m #home #busywork”. When you’re at home, your mind is completely fried, and you have 15 minutes to kill, having these tags helps you find the tasks that should be done at that point in time. When we have 15 minutes to spend, knowing exactly what we’re going to spend that 15 minutes doing is essential.</p>

<h2>3. Name lists by major projects/efforts</h2>

<p>When organizing my to-dos, it’s cognitively helpful for me to think about my home chores, side projects, and work projects in different contexts. Thus, when I’m thinking about writing articles, I have a list dedicated to writing articles. I can tag things to fall back to related tasks, like #writing, which I can put both on my book-writing efforts as well as my personal writing efforts.</p>

<h2>4. Share lists with my wife, coworkers, etc</h2>

<p>Shared lists are another killer feature.</p>

<p>My wife and I always need the same groceries. So, when we go grocery shopping, having the list available is super valuable. Pro-tip: when you run out of something, mark it off the list, and use the “completed” view to show you what you need to buy. Much easier than unmarking. Once you’ve bought everything, clean up your “completed” by marking them as “incomplete”. Dirty, but usable.</p>

<p>Sharing a list means you can also assign items. This makes divvying up responsibilities a breeze.</p>

<h2>5. Make a Must Do Today list, and limit it to 3 items</h2>

<p>If you don’t have a priority list that is your daily requirement, then you don’t really have an “in-queue” context. Make these non-negotiable, and make them completely accomplishable.</p>

<h2>6. Make Managing your List its Own To-Do</h2>

<p>Your to-do list is built to take care of your <em>meta-work</em> - your work about work. Stop thinking about what it is that you have to do, and pull it off the top of your list. This means it takes time to manage your list. So, dedicate some time to administering your list. Simple as that, you’ve done all of your meta work, which otherwise would steal from your insignificant cracks.</p>

<h2>7. Make everything actionable</h2>

<p>Make each and every item on the list an actionable task. This means no “get ready for the event” kind of tasks; instead, use “email the participants of the event”. Pro-tip: Use the comments and sub-tasks in Wunderlist to keep track of minute details. For instance, if you need to individually email a list of people, put each person as a subtask of the email task. Use comments to grab relevant links, passwords, etcetera.</p>

<p>I’m using Wunderlist because it makes my task management easier. Hopefully you find these tips useful to your task management. <a href="http://twitter.com/jcutrell">Let me know what you think on Twitter!</a></p>


7 Tips for Hyper-productive Wunderlist-ing


## Update: I've abandoned this project for now.
It's important to know when to leave something behind.

<p>I’m more than excited to announce that I will be publishing a book soon that’s all about the work I do on a day-to-day basis with some incredibly creative people here at <a href="http://whiteboard.is">Whiteboard</a>.</p>

<p>In the book, you’ll find ideas that I believe could change the way developers and visionaries work together, and I’m really excited to share it with you.</p>

<p>If you’re interested in learning more about the book in the upcoming days, drop by <a href="http://hackingtheimpossible.com">http://hackingtheimpossible.com</a> and sign up for the mailing list, and then follow <a href="http://twitter.com/hackimpossible">@hackimpossible</a> on Twitter.</p>

<h2>About the book</h2>

<p><a href="http://img.svbtle.com/4b6uympiv3gy8q.jpg"><img src="https://d23f6h5jpj26xu.cloudfront.net/4b6uympiv3gy8q_small.jpg" alt="hti_cover.jpg"></img></a></p>

<p>If you work at a creative agency, you’ve almost certainly experienced the phenomenon of personality difference that Hacking The Impossible is all about. The two polar creative opposites - The Developer and The Visionary - sit in their corners of the room, each with entirely different understandings of what it means to <em>work</em>. The developer believes in concrete structure and receives in equal portions nerd-ridicule and geek-cred; the visionary follows the latest fashion trends and seems to shift from one idea to the next, living in complete oblivion to the complexity of technology. The developer is often accused of being anti-social, closed-minded, or pessimistic, while the visionary is accused of having their head in the clouds, getting wrapped up in impractical or downright impossible ideas.</p>

<p>The truth, however, is that the powerful creative abilities of each of these polar opposite caricatures are held within their ability to be the extreme versions of themselves. The visionary holds keys to imagining the impossible things, and the developer’s job is to build the impossible.</p>

<p>This book is about two things: how to work better with people, and how to use those skills to think about problems in a new light. This new light illuminates the path to innovation, and reminds you that with the right people in the right room at the right time, the impossible can be achieved.</p>

<p><strong>Don’t forget to sign up for the mailing list at <a href="http://hackingtheimpossible.com">http://hackingtheimpossible.com</a> to receive periodic updates from me about the book!</strong></p>


Announcing Hacking the Impossible &#8211; The Developer’s Guide to Working with Visionaries


<p>As I’ve said before in <a href="http://jonathancutrell.com/steal-these-startup-ideas-collection-one">collection one of this series</a>, ideas are everywhere. Furthermore, I certainly don’t have time to make all of my ideas a reality. I want them to be real, and truly would use each and every one of these.</p>

<p>If you like one of the ideas and want to take it and make it a real thing, let me know! I’m not going to try to take a piece of your company (unless you offer and the deal is a good one), and I’m not going to sue you. I just want to hear from the people these ideas are influencing. It fuels me! Tell me on <a href="http://twitter.com/jcutrell">Twitter (@jcutrell)</a> or email me at <a href="mailto:jonathan@whiteboard.is">jonathan@whiteboard.is</a>.</p>

<p>Enough of the introduction - let’s talk about things that would make the world a better place, shall we?</p>

<h2>1. Service Butler</h2>

<p>How many services do you subscribe to? Sometimes I even forget how many I’m subscribed to. However irresponsible that may be, I certainly get a lot of benefits out of services. But I’d like to be sure that I’m spending my money wisely, which means two things:</p>

<ol>
<li>The services I’m buying are the best for the buck</li>
<li>I save money if and when possible</li>
</ol>

<p>Imagine a service that allowed me to lean on my personal service butler - who could do the research to find me savings and refine my list of services, consolidating and managing all customer service issues as my representative. On top of managing my services for me, they could also take cuts of my savings for themselves (I’d rather save 2 dollars and give one away than save none at all). What’s even more exciting in this? The opportunity for affiliate sales.</p>

<p>Pro tip/warning: Do NOT do this idea and take any and every affiliate deal that comes your way. Then the core competitive advantage and selling point - that you are my butler, and you’re on <strong>my side</strong>, is lost. Only take affiliate deals that you believe in. This is really true for all affiliate sales, too.</p>

<h2>2. Facetime Health Checkups</h2>

<p>I’m a relatively healthy individual, but I’d like to be sure I’m doing everything I can to remain healthy.</p>

<p>I’d definitely pay for a convenient way to get professional medical advice without having to sit in a waiting room. Sometimes, I have a simple question about fitness, food, or behavioral patterns that I’d like answered, and I can’t really get that answer right away unless I ask Dr. Google. I’d much rather have a nutritionist that I can Facetime or Skype with, so that I can show them my pantry and ask them random health questions. Furthermore, they would know my medical makeup and family history, so they would be able to give me more personalized advice than something like Google.</p>

<p>Disclaimer - there may be a TON of HIPAA stuff standing in the way of this actually happening, or it could be as easy as just doing it - I don’t know. That’s your job to find out. However, this is the wave of the future - if you are an early builder in the field of remote medical, you’d be quite smart in my opinion.</p>

<h2>3. Box-a-Month Closet Builder for Men</h2>

<p>Sure, there are plenty of subscription box companies, and some of them are awesome. But what I need to focus on is building my professional wardrobe in a consistent way. I also want it to match my personality.</p>

<p>(Note: I’m focusing on men because it seems like it’s the most obvious market for reasons I outline below, but perhaps there is an adjacent market focusing on women’s fashion. Have at it.)</p>

<p>Combine learning algorithms with sizes and fashion personality traits, and you have yourself a nice pipeline to serve men the fashion they need on a monthly basis.</p>

<p>If there are other men like me (I’d imagine I’m not THAT unique), then fashion isn’t always at the top of their priority list. Like many things, I and they are willing to pay to not have to make fashion decisions. I’d rather it be dependable and automatic. Build my wardrobe for me over the next few seasons, and do so with the proper flair, and I will definitely pay a monthly subscription fee. Maybe even a variable fee. Think about opportunities for upsell and product placement!</p>

<p>Go make this one happen, please.</p>

<h2>4. Mentor-Mentee Matchmaker</h2>

<p>I’m in search of a mentor. I’m also in search of mentees. The benefits of teaching and learning from other people are numerous, and we won’t detail them here. Instead, let’s focus on one simple fact: there is no platform dedicated to creating, building, and supporting mentor-specific relationships.</p>

<p>Imagine you create your personal profile. Talk about your income, your goals, and your skillset. Maybe even explain some of your personality traits.</p>

<p>Do the research to find out what mentor-mentee relationship dynamics work the best, and build your algorithms around those concepts.</p>

<p>Then, make matches. Find people who have financial goals and match them with those who have found success in their finances. Or, maybe more complex relational dynamics could play into the relationship, such as an extrovert teaching an introvert about self inclusiveness or confidence.</p>

<p>The opportunities here are in the data, of course, but also in the relationships that are built. Creating a company that births learning in whatever format is going to pay for itself a hundred times over.</p>

<h2>5. Educational Pathmaker: Using Data to Drive the Classroom</h2>

<p>Education is clearly a field that requires more energy and resources from all possible angles.</p>

<p>The need for a data-driven approach to personalized curriculum and educational planning could change the way schools work across the world.</p>

<p>Imagine, for instance, that the patterns in 90% of children who may have autism are present in a student. At what age is it detected that that child may be autistic? Perhaps young, but perhaps not. If there was a computer-aided analysis that helped determine the cognitive abilities of a child dynamically as they progress through their education, better decisions could be made for that child’s education.</p>

<p>This opens up not only the reactive scenarios, but also proactive scenarios such as cognitive research. If children demonstrably respond better to a particular curriculum, this becomes like A/B testing for education programs. Imagine the ability to start determining career paths earlier in life based on natural tendencies, or even based on seemingly unrelated personality or behavioral attributes a given student presents.</p>

<p>Furthermore, this would help provide a selection process for classroom placement, and could possibly even help reduce violence in schools by identifying children who need more specific psychological attention.</p>

<p>The ethics of this particular system are obviously the big question mark. The outlying statistics. What happens when the algorithm is wrong? Obviously, the answer to this question is to never trust the computer more than you trust reality. This is the future of education as well - highly personalized educational paths that are responsive to your cognitive abilities and behavioral patterns.</p>

<h2>Conclusion</h2>

<p>I hope you’ve enjoyed this second collection of ideas! The goal is to continue these installments, and hopefully continue to make better relationships with you, the reader. In the meantime, shout out and follow me on <a href="http://twitter.com/jcutrell">Twitter</a>!</p>


Steal these Startup Ideas: Collection Two


<p>Fifth-degree black belt.</p>

<p>Doctorate.</p>

<p>Rocket scientist. Triathlon competitor. Fighter pilot. Franciscan Monk. Astronaut. World-record holder. Five-star General. Firefighter. Navy SEAL. Everest scaler. Antarctic explorer. Olympian.</p>

<p>What comes to your mind when you read these titles?</p>

<p>For some, these titles were the answer to “what do you want to be when you grow up”, before they grew up. For others, these titles represent an obvious demand for respect. What’s invariably true is that none of these titles is <em>easy to attain</em>. In fact, quite the opposite; to earn any one of them, one would have to invest an enormous amount of energy and commitment.</p>

<p>What’s more - we attach a sense of elitism to these labels. Perhaps that’s why we wanted to be one of them when we grew up. We naturally have an appreciation for the difficult-to-attain. But why?</p>

<h2>Our Addiction to Simplicity Ignores Our Affinity To Challenge</h2>

<p>As designers, entrepreneurs, developers, etcetera, we often believe it is of utmost concern to make everything “simple.” We have taken Rams' principle of “as little design as possible” and over-extend it to mean that <em>anything difficult is evil.</em></p>

<p><strong>This is not the case.</strong></p>

<p>In fact, Rams' idea of making something simple should be reframed: design should be easy to understand. Actions should be clear, but not always easy to accomplish.</p>

<p>Let’s take P90X as a ubiquitous example. If you haven’t heard of P90X, you probably don’t watch TV at 3AM… but if you do, you know Tony Horton quite well. He’s that guy reminding you how lazy you are, but also letting you know there’s a path to no longer being lazy via his infomercial.</p>

<p>It’s not an easy path. It’s not a short path. It will take a lot from you, but if you commit to it, a lot of other people who have committed and followed through show you proof that you’re likely to see results. You can get ready for the beach, but it’s going to take putting yourself through 90 days of hell.</p>

<p>I am in no way affiliated with Beach Body, but I find this phenomenon fascinating.</p>

<p>Why would somebody commit to something that is so difficult? Why would they pay a significant sum of money just to hear someone tell them to push themselves harder than they are comfortable pushing? Haven’t we learned that people only do things that are easy and obviously rewarding?</p>

<p>People have the capacity and drive to do hard things. We have that natural affinity to the hard-to-attain - an affinity to <em>challenge</em> that causes us to pick up the phone and order those P90X DVDs, not just because we want to lose our soda-and-Cheetos-weight, but because Tony looks us in our collective faces and gives us a challenge worth engaging.</p>

<h2>Challenge: Competition, Achievement, Worth</h2>

<p>I believe we have such an affinity to challenge for at least these three primary reasons.</p>

<h3>1. Competition</h3>

<p>I’ve been watching the College World Series this year. (In fact, it’s playing in the background as I write.) I’ve never watched baseball until this season, and it’s my new sports addiction.</p>

<p>We watch sports because we love competition and collective identity. We even mindlessly attach ourselves emotionally and face-paintedly to a team, without any logical connection, because we identify with competition and create an identity space for ourselves by joining in the highs and lows of fanhood. Why is so much energy, emotion, and resources put into a game? Because we fundamentally are wired for competition. We self-actualize by competing, giving definition to our place in humanity and in our individual communities by adding the dynamics that come with winning and losing, and the excitement of the tension of the game.</p>

<h3>2. Achievement</h3>

<p>The psychology of Flow (<a href="http://en.wikipedia.org/wiki/Flow_(psychology)">as defined by Mihály Csikszentmihalyi</a>) requires two things: a high skill level and a high challenge level. Furthermore (directly from the Wikipedia summary), flow requires these conditions:</p>

<blockquote class="large">
  <div class="inner">
    <ol>
    <li>One must be involved in an activity with a clear set of goals and progress. This adds direction and structure to the task.</li>
    <li>The task at hand must have clear and immediate feedback. This helps the person negotiate any changing demands and allows them to adjust their performance to maintain the flow state.</li>
    <li>One must have a good balance between the perceived challenges of the task at hand and their own perceived skills. One must have confidence in one’s ability to complete the task at hand.</li>
    </ol>
  </div>
</blockquote>

<p>In other words, challenges aren’t really challenges if they are impossible, but they need to be at the edge of our skill set. “Flow” state gives us a sense of movement and achievement.</p>

<h3>3. Worth</h3>

<p>When we can compete with others, we understand who we are in relation to our competition. When we experience achievement, we naturally develop self worth. <em>We recognize that we have done something significant.</em></p>

<h2>Design Challenge</h2>

<p>Perhaps we have an inappropriate amount of value placed on simplicity. Maybe we should take a chance to challenge those engaging with what we create - to ask them if they are willing to do something harder. To invest in doing something: time, money, energy.</p>

<p>Did you set your pricing strategy based on making it easier for the user? Consider the worth your users attach to something they invest in versus something free.</p>

<p>Does your sign up form let anyone with an email address register for your application? Consider requiring users to justify their membership by asking them why they want the membership.</p>

<p>What classes are worth taking? What weights are worth lifting? What walls are worth climbing? Trails are worth hiking? Miles worth running? Time, money, energy worth spending?</p>

<p>Ask this question of yourself: Are you taking away the opportunity for your users to face a challenge worth facing, and trading it for “simplicity?”</p>

<p>What does this say about the worth you place on what you create? Most times, the most rewarding things require challenge. Open a conversation with your users. Be clear, and make it simple, but don’t lower the barrier to entry by making everything easy to accomplish.</p>

<h3>Your new marketing pitch:</h3>

<blockquote class="large">
  <div class="inner">
    <p>This is going to be very difficult, but once you’ve gone through it, it will have been worth it. And we are here with you every step of the way.</p>
  </div>
</blockquote>


Make Me Work for It: Challenge Psychology


> Great things are done by a series of small things brought together.
> **- Vincent Van Gogh**

> Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
> **- The Unix philosophy**

<p>How many of your successes came from complex, massive projects?</p>

<p>The world is made up of simple things, and when we try to create our “big” ideas, we have a tendency to fail. The idea of making something simple does not mean making something easy - it means putting more concentrated attention into fewer details.</p>

<p>WhatsApp. A brilliantly simple concept. I don’t care to discuss the valuation - I care about the fact that it’s used and validated widely. I care about the fact that the design and conceptual approach worked, and all it does is… something small.</p>

<p>At Whiteboard, some of our most effective work has happened over the course of afternoon sprints. This happens because good ideas don’t necessarily rely on a complex network of supporting features, but stand alone. Good ideas often, perhaps almost always, directly address a small, simple problem.</p>

<p>This isn’t to say that we don’t give time to research and fermentation of ideas, but rather to say that we focus on a few ideas intently, and the execution of a solution often occurs very rapidly.</p>

<h2>Build Small, Lose Small</h2>

<p>Building small means failure is less painful. Building small leads to a higher volume of ideas and more intentional, deep exploration of single ideas, leading to highly predictable outcomes. Building large, on the other hand, usually means a plethora of poorly executed remixes of previous ideas with little predictability.</p>

<p>Building small means your ideas can easily be combined. It means you can test earlier, and rebuild from ground zero with little to no loss, as the value of your efforts is on the <em>knowledge</em>, not the product.</p>

<h2>Small Means Easier…</h2>

<p>When you build small, you build less maintenance overhead. It makes debugging easier. It makes testing easier. It makes marketing and the road to profitability clearer (maybe not easier). It makes scaling easier. Ultimately, the things that should be easier become easier with a smaller idea.</p>

<h2>Small Means Harder…</h2>

<p>Because you have to be good at what you do. Really good. You have to win at making fundamental ideas come to life, because when you build small, there are no bonus features. When you build small, transparency and purity shove your work out into the open. Every small detail is in plain view, because there’s less to get lost in. If you build small, you take on a challenge of creating boutique, focused experiences that ultimately get at the core spirit of the problem you’re solving.</p>

<h2>Do Less, More Often</h2>

<p>The challenge I present you with is to execute smaller ideas to perfection, and do so repeatedly. Small, beautiful, proper nouns are still in high demand, so make Small Things.</p>


Create Small Things


<p>One thing I’ve been able to do in my writing career is… well, write. Perhaps the better way to describe this is to say that I have a knack for not getting stuck in writer’s block.</p>

<p>I didn’t realize this was a skill until a coworker recently asked me about my writing process, and inquired into how I get from zero to finished without many hitches.</p>

<p>(He should see how many unfinished articles I have in my Svbtle queue, but nonetheless…)</p>

<p>I started explaining my process. Usually, my ideas come from a conversation (as an example, see the article you are currently reading). Next, I write what I’m thinking.</p>

<p>I don’t marinate on the idea for very long. I don’t try to fully construct my argument. I don’t map out the sections. I just write, unadulterated and usually raw.</p>

<p>Most of the time I make many references to things that others don’t understand. I’ll make some strange comparisons and synthesize fairly obscure meaning out of thin air. But I write.</p>

<p>Then, I go back, check my headings, rewrite the things that don’t make sense, and if something good comes out? Publish. Iterate.</p>

<p>The truth of the matter is, so many people get caught up on their inability to write cohesively. To write something compelling. We all think a major amount of research is necessary, probably because we’ve been poisoned by academia to believe our own thought isn’t legitimate - that we can only speak from anecdote.</p>

<p>But no one is grading these papers. People read anecdotes. You don’t need to formulate the perfect argument every time you sit down to write. Instead, you absolutely, without fail, must tap into some kind of core human emotion inside of you, and let that emotion inform the flow of your words. Perhaps this is why my best writing comes from conversational topics. My emotions are peaked in conversation, and things that move my emotions are often likely to also move others.</p>

<p>There’s no pride in that necessarily - we are human. Emotions are powerful, and starting your writing in emotion is perfectly viable.</p>

<p>Of course, that doesn’t mean you shouldn’t edit. And edit again. It also doesn’t mean you can rely solely on emotional appeal to prove your argument.</p>

<p>This isn’t about whether or not emotion is a viable alternative to logic or reason, as it certainly isn’t. Emotion guides you towards intuition. When you tap into emotion, words become fluid, and writer’s block seems to stay at bay. You stop second guessing and examining the idea - practices which kill your output - and instead you focus on the fact that you have something to say. Ultimately, if you are a writer, having something to say is the most important skill you can achieve.</p>

<p>Think of your writing as an architect thinks about a new building plan. If you first approach your writing by constructing the technical requirements, toiling over the debate-style point-by-point inspection, you are effectively trying to build the schematics for a building first. Instead, you should cast your vision for the building by painting what you feel it should be. The details of that approximation are fleshed out in editing phase.</p>

<p>Write without the rules in mind. Contradict yourself. Commit every logical fallacy in the book. Allowing your human tendencies to be present in the first phase of writing is incredibly important.</p>

<h2>Why does this work?</h2>

<p>I strongly believe the reason this works is because <em>“writing” isn’t one discernible practice</em>. Instead, it is a collection of practices that should be treated as separate, distinct skills that are combined into a singular super-skill.</p>

<p>Writing is:</p>

- <em>Output</em>: This is what we’re talking about in this article, for the most part. This is where people end up getting “writer’s block”, and is absolutely the primary, most essential part of the writing process.
- <em>Research</em>: Research occurs in so many different ways. For me, research isn’t purely academic. It’s coincidence, experience, and consumption all in one. Research performs two roles as it relates to your writing: <strong>informing</strong> and <strong>validating</strong>.
- <em>Editing</em>: Editing occurs throughout the process. We do both simple editing (wherein we correct our “alright"s to "all right"s), as well as complex editing (wherein entire sections are nixed, and the necessity for new sections arises). Editing is informed both by your output and research, but will also affect your output and research significantly.

<p>If you can do the three of these things well, I believe you can write well. What’s more, it takes a massive amount of fluid output to be able to effectively research and edit. If you are experiencing writer’s block, ask yourself these questions:</p>

<ul>
<li>Am I trying to over-validate my idea?</li>
<li>Have I hit a roadblock because I’ve lost my argument along the way?</li>
<li>Should I start fresh, or should I shift modes into editing to re-align myself on the emotional track?</li>
<li>Am I trying to fast-forward to a post-output stage?</li>
<li>Am I actually invested in the idea I’m writing about? Where did the idea come from, and do I care enough to keep writing about it?</li>
<li>Do I believe in my own writing enough to be authoritative on the subject I’ve started authoring?</li>
<li>Am I just trying to avoid a longer editing process by writing it "right the first time”?</li>
</ul>

<p>Answering these questions should help you find a shift in thought that will put you back in the output stage. Never write without authority. Don’t trade emotion for logic. Write with your feelings. Paint your buildings first.</p>


Getting Past Writer’s Block: Break the Rules

<p>I recently encountered an interesting situation with a client. We were talking on the phone about a priority list of features they need on a platform we built; a while into the conversation, they mentioned that they felt like they had already told me all of the problems they were listing.</p>

<p>I was somewhat confused and surprised, because the problems they outlined seemed new to me. Then it hit me.</p>

<p>They had asked for particular features in response to their business problems.</p>

<p>The truth is, business problems require solutions. But it is our job as designers and developers to determine the most usable, maintainable, and effective solution for the platform and user scenarios.</p>

<p>Your clients may often ask you to implement a specific feature. Instead of nodding and pounding on your keyboard, talk about the root problem. Figure out what it is they experience day to day - get a true intuition for the problem, not the desire. Then, and only then, devise a solution better than anything they could do. It’s not their job to solve their own problems. They hire you to do that.</p>

<p>So encourage your clients to share their problems instead of their solutions. This kind of communication is key to effective long-term solutions.</p>

<p>As for the client, we now have a regular call scheduled for them to explain the problems they are experiencing. I then will take their issues and solve them, piece by piece.</p>


Feature Requests vs. Business Problems


<blockquote className="large">
  <div class="inner">
    <p>When you make a design decision, understand that there is no single more important guideline to follow than an equal balance of your own intention and the consumer’s situation.</p>
  </div>
</blockquote>

<p>Often, conversations discussing the usability implications of a particular design decision spike on HN/DN, bringing opinions out of the wood work. Whether you are talking about <a href="https://news.layervault.com/stories/2847-why-has-hiding-navigation-menus-behind-icons-suddenly-become-acceptable">the hamburger icon</a> or <a href="http://www.fastcodesign.com/3023690/evidence/snow-fail-do-readers-really-prefer-parallax-web-design">whether parallax is a good idea</a>, the opinions of readers shift wildly.</p>

<p>As I said in a <a href="http://www.creativebloq.com/mobile/whiteboards-all-or-nothing-approach-responsive-web-design-121310191">recent interview</a>, there is no one guiding factor for design. Design is, in many ways, subjective.</p>

<p>Before you usability engineers jump down my throat and describe the difference between art and design, let me go ahead and stop you. Design and art are not two separate things entirely; instead, art is borne of design. An artist designs a particular piece (be it performance, visual, or purely conceptual) with some kind of intent, even if the intent is to be void of intent. And thus, if the intent of a given piece is to communicate pure chaos, then you must throw away any preconceptions of a design approach.</p>

<p>Do excuse me for my grossly obvious post-modernism spiel. As much of a diversion from common web design this may be, this principle holds: the intended message and identity of a given work, in combination with the context of the intended audience, provide the only valid guide for which a designer may make decisions.</p>

<p>And so we arrive at a good, albeit challenging, framework by which to run our design decisions through.</p>

<p>Take, for instance, the save icon.</p>

<p>Does it make sense to use a hard disk to represent “saving” a document? By purely observational standards, with no context, absolutely not. Hard disks have long been gone. It’s roughly akin to using a typewriter to represent a keyboard.  Why, then, do we continue to use the save icon?</p>

<p>The answer is fairly simple: contextually, the disk icon means save (maybe even more than it means “disk”) to most users. Of course, we are moving more towards the symbolic understanding of cloud over disk, but all of this is representation.</p>

<p><img src="http://2.bp.blogspot.com/-ETwjbcA56Vk/UVj7IF0b3VI/AAAAAAAAEzk/ro_3mUmiyWY/s1600/Cloud+Save+Icon.png" alt=""></img></p>

<blockquote className="large">
  <div class="inner">
    <p>A cloud disk drive, found via Google Image Search. Literally.</p>
  </div>
</blockquote>

<p>That context helps us understand decisions more accurately.</p>

<h3>Square buttons, flatness, etcetera.</h3>

<p>A coworker of mine recently asked me what the “best practices” are for buttons. I found an article explaining some of those, such as being sure that the buttons “look like buttons”, whatever that means - including the need for rounded edges.</p>

<p>I then changed tabs to Facebook, probably to waste some time, and saw that Facebook had indeed adopted a square button.</p>

<p><em>Someone’s got it wrong, right?</em></p>

<p>Not necessarily. The truth is, people evolve. <a href="http://frankchimero.com/intros/quilt/">Frank Chimero</a> explained this evolution beautifully in his brilliant transcript of <a href="http://frankchimero.com/talks/what-screens-want/transcript/">What Screens Want</a>, saying that people use things like clouds and disks and trash cans and other representations (he calls this “padding”) to help them grasp what the functionality of those things are. A button in real life is rarely perfectly square, so why would a button in the digital world be square? The answer is relatively complex, but the short answer is, our brains won’t always need padding. We won’t always need to consider things on our screen to be related to things in the real world, and thus we can grasp the squareness of buttons just fine.</p>

<p>Furthermore, Facebook is quite big. You won’t catch me saying that makes them invincible, but it allows them to push usability standards further. In other words, Facebook users want to post a status, and they will probably figure out how to post a status no matter what shape the button is. They are invested, and Facebook can make huge changes to their platform (or rather small ones, as well) without much of a consequential hit on usability or user engagement. How many times have you heard people complaining about how much they hate the “new Facebook”, only to complain again when it changes again? (It always amuses me that the complains show up on Facebook.) They stayed. The posted statuses. They learned to use new feeds and mini-feeds and, believe it or not, <em>square buttons.</em></p>

<p>And because of Facebook’s relative audience, we can safely assume that people have a pretty good idea how to use square buttons, now that Facebook has trained them.</p>

<h2>Where it might break down</h2>

<p>We can’t safely assume that people can learn <em>anything</em>, just that they can learn many things. I’d argue that a good number of the design decisions in iOS7 were a bit too far of a jump, too much of a drop in padding if you will, for people to keep their grasp. Sure, we all (read: most of us) probably use iOS 7 perfectly fine, but it certainly hasn’t been a seamless transition. Was it a bad design decision? It depends on the intention of Apple, which I think is to continue being the leader in making things that screens want, rather than only things humans are comfortable with. Apple, like Facebook, can break down a few barriers of design without a large backlash. The backlash comes when you design something that simply doesn’t work (like Maps).</p>

<p>But it’s not just bad directions that can break a design. It’s a bad understanding of humans that can break a design.</p>

<p>I’d label Google Glass’s debut a fairly ineffective launch; it hasn’t done what we as designers wanted it to do. But why? Well, one answer might be that they’re really, really quite awkward to wear for many users. Another might be that they are so unnatural in daily life, that the user couldn’t make the leap to full integration, which is what the device is intended to accomplish. This is a problem solved by time and cultural saturation, most likely, as cell phones and cars and clothing were at one point completely unnatural as well.</p>

<h2>A conclusion</h2>

<p>Be careful with design decisions by remembering who your audience is, and what your intention is for the thing you are designing.</p>


Design Decision Guidelines: Trendability vs. Usability

<p>The Internet of Things is absolutely upon us.</p>

<p>Whether you’re fully aware and plugged in to tech rumor blogs and things like <a href="http://iotlist.co/">iotlist.co</a>, or if you’ve never heard the term before, the Internet of Things is a huge wave in the way we think about technology.</p>

<p>A brief summary: everything is connected to the internet (is connected to everything), and everything is everywhere.</p>

<p>That’s the groundbreaking idea. To have an internet of things, you must have not only complex, multi-tasking machines like laptops and smartphones that connect to the internet, but also common elements of your every day life that connect to the internet. <a href="http://www.meethue.com/">Lights</a>, <a href="http://www.samsung.com/us/smartappliances/">washing machines</a>, <a href="https://store.nest.com/product/thermostat/">thermostats</a>, <a href="http://signup.driblet.io/">faucets</a>, <a href="http://shop.whistle.com/cart">pet collars</a>… You get the idea. If you don’t, try Googling an appliance, or really almost any concrete noun, followed by “wifi”.</p>

<p>This isn’t about a big red sticker saying “new and improved, now with WIFI!” - what it really comes down to is a different perception of control interfaces; I already do so much on my phone, why not centralize everything? Let me wash my dishes, pay my bills, set my DVR, and <a href="http://petcube.com/">entertain my pet</a> directly from my phone. And give me visibility to anything, anywhere. Oh, and save me some money in the process.</p>

<p>And it’s happening! It’s happening in my home, and it’s probably happening in yours. My nest has saved me… I don’t know how much money, but I really enjoy using it. And my Hue lights flash red when Alabama scores.</p>

<p>The ubiquitous dream. One day, the walls will be screens. Our homes will have ears, and our eyes will be everywhere. (This isn’t a discussion about privacy - imagine it’s magically solved.)</p>

<p>But let’s think further, beyond nouns. Let’s think in sentences, as humans do. Think about the context of our wifi-empowered nouns.</p>

<p>Context is everything. And the Internet of Place is the evolution of the Internet of Things. Things are nothing without their context, and the connectivity of things will only be followed by the connectivity of place.</p>

<h2>Distinguishing Place From Space</h2>

<p>At Georgia Tech, I studied mobile applications under <a href="http://ledantec.net/">Christopher Le Dantec</a>. One of the primary themes of Chris’s work is understanding the relationship of mobilized technology as it relates to place, and the social science that turn a <em>space</em> into a <em>place</em>.</p>

<p>To unpack this a bit, let’s think about the lot that your home is built on. Scientifically speaking, that space has dimension and material makeup, and resulting properties. The space is located at a particular latitude and longitude.</p>

<p>Without any social understanding, the meaning of this space is lost.</p>

<p>Let’s start with sociocultural understanding: what country does that latitude and longitude land in? What state, city, and perhaps most importantly, what neighborhood?</p>

<p>We can get a sense for the mass sociocultural meaning, but what about the micro-cultural meaning in the space? A more elementary way of asking: who is your neighbor?</p>

<p>Now, the richest meaningful aspects of the space: who inhabits the space? Who has built the human history of participation in the space?</p>

<p>We attribute value to these things, both conceptually and concretely. Book two hotel rooms, exactly alike on their face; if one of them once held the President, I’d bet you’d be charged more for that room. Why? The space is the same; the place is different.</p>

<p>And truly, places aren’t the same to each person who comes along. The run-down garage where you and your father worked on your first car when you were a kid has a market worth of nearly nothing. But to you, it’s priceless.</p>

<h2>The Internet of Places</h2>

<p>Arguably, the most powerful motivator for technological innovation is the opportunity to empower us to make meaning in our lives more richly. The Internet of Things gives us the material to do this, but the Internet of Place gives us a full vocabulary.</p>

<h3>What does it look like?</h3>

<p>The Internet of Places will likely be made up of context aware applications combined with higher level machine learning to develop a sense of place-oriented interaction. Let’s imagine a few scenarios.</p>

<h4>Football Game</h4>

<p>I enjoy football. Going to a football game to me is a memorable experience. How awesome would it be for the stadium to know I was in it, and display my presence on a digital wall of inhabitants? Or maybe it’s as simple as having an application that allows me to press a button to order my hot dog and Coke from my seat so I don’t miss a play. This is absolutely possible right now with almost zero technological innovation. A more lofty scenario: my Google Glass listens to the game, and based on analysis of voice tension, language analysis, and game data, automatically records my perspective of the big plays. Later, I can go back and identify the ones it got right (hey machine learning folks - there’s your correction feedback loop), and share my perspective of the incredible touchdown pass. My memory of that play isn’t what they show on ESPN - it’s what I saw. This enriches my ability to revisit my important memories.</p>

<h4>Shopping</h4>

<p>Dear stores: Buy iBeacons and make awesome experiences for your buyers. Trade them their personal info for coupons. (Be responsible with their info.)</p>

<p>Imagine for a moment that you are in Wal Mart, and you can’t remember what you need. Your digital world remembers though, and your phone knows you’re at Wal Mart. You no longer keep a list of things you need to buy - your phone has already pre-ordered them and they are ready for you to pick up. (This seems like a very complicated scenario, but this is essentially how inventory management happens at the Wal Mart level; why can’t it happen at the My Home level, too?)</p>

<p>Another shopping example: you’re shopping for clothes. Your device of choice is your companion, letting you know what stores have your sizes in stock, and checking whether those sizes run smaller or larger than average. When you walk into the store, your device identifies, based on your past purchasing behavior, current fashion trends, local fashion trends, and friend comparisons via Facebook (or whatever network you choose), what you are most likely to genuinely be interested in. Perhaps a score is assigned to outfits, identifying things that are “out of the box” vs things that are “popular mainstream”. (Don’t crucify me - I’m not a fashion guy.) These value decisions you usually make on your own are now more informed. You have more confidence in your decisions, and the store has better information about you to ensure that your size is in stock next time you come in.</p>

<p>The implications are absolutely ginormous for retail; employing higher level learning algorithms for massive communities would change the concept of “lead time”, and could potentially virtually eliminate a massive margin of error in most inventory prediction methods.</p>

<h4>At Home</h4>

<p>When it comes down to it, what people want out of a smart home doesn’t put the emphasis on <em>smart</em> - it puts the emphasis on <em>home</em>. And that happens with context. For now, we have hyper-configuration, a tinkerer’s dream. Philips Hue lets me set a mood, for instance. We’re moving towards contextualization with automation and pipelines like IFTTT, and the next wave of home automation will move even further this direction. My home should know when it’s my anniversary, when I have friends coming over, and when I’m on vacation. I should be able to see meaningful analytics about my energy usage as it relates to my <em>activities</em>, not just simply the time of day. I don’t want my home to be a house-shaped human - I want it to be a representation of the people that live in the home.</p>

<p>My masters project was a good example of creating placeness in a home (or anywhere that music is played in an open space). I created an application that allowed people to check in to a given location, and would dynamically select music using everyone’s collective preferences. Once the person leaves the space, their effect on the music preferences decay over time; if they are a “regular”, their preferences remain strong for longer. This concept perpetuates a sense of collective identity of a place and its history.</p>

<p>The future of smart home technology doesn’t just let you set your alarm from anywhere in the world, or give out digital keys to let your friends in the front door. It knows you - it learns your moods and your behaviors, and connects with your personality. And not in a creepy invasive way, because your home isn’t personified. Instead, it picks relevant pictures and lighting to show on screens. It gives you suggestions for outfits on a given day, because it knows your wardrobe. It makes your coffee when you begin to wake up in the morning (instead of on a static timer). It keeps track of your belongings for you so losing your keys never happens again. Your presence isn’t simply presence; it’s contextualized presence.</p>

<h2>Conclusion</h2>

<p>The future of the Internet makes placeness a primary consideration, and elevates the Internet of Things. We begin to see machine learning conforming not only directly to measurable data, but also to subjective data - artificial intelligence in it’s smallest, most domain-specific application.</p>

<p><a href="https://news.ycombinator.com/item?id=7300193">Discussion on Hacker News</a></p>


The Internet of Places: The Context of Things

<h2>They died.</h2>

<p>I have seen these words on my screen countless times. I fear them, in many ways, as they seem to hit closer to home all of the time.</p>

<p>Fear of death isn’t irrational - I know that when someone I love dies, it will be painful. It is natural, but that doesn’t make it easy to bear.</p>

<p>What is irrational is believing that death is related to proximity (except in horseshoes and hand grenades). However irrational it is, when something “hits close to home”, it can have a chilling effect, and if you’re anything like me, it can cause anxiety.</p>

<p>Irrational or not, when those words pop up on my screen, I immediately think about the proximity of death to those that I love.</p>

<h2>Bad news makes the headlines.</h2>

<p>And when I say headlines, I mean not only the ones on your TV, but also the ones in your browser (read: the top post on Facebook, or Hacker News). People attach themselves to bad news, for many reasons; sometimes it is because, quite simply, it is genuinely bad for that person. Like when someone they are close to is going through something horrible. Whatever the reason, this attachment naturally causes bad news to rise to the top. Thank you brilliant algorithms: bad news (amongst cats, surveys, and Candy Crush) is effectively micro-viral.</p>

<h2>Bad things happen to everyone.</h2>

<p>You know, everyone goes through tough times. And that shouldn’t be downplayed. When we see these headlines in our news feed, they are certainly not usually disingenuous. But unfortunately, while bad things happen to everyone, on average, many more <em>good</em> things happen. These things unfortunately don’t make the headlines as often, though. Normal, happy life isn’t viral.</p>

<h3>A Time for Mourning</h3>

<p>We’ve reduced mourning to comments on a feed.</p>

<p>It used to be the obituary section that housed this information. We would intentionally participate in a process of mourning with loved ones. We would either seek out the information, or the affected would contact us in some more direct way to inform us of the bad news.</p>

<p>Now, it’s broadcast.</p>

<p>And we participate in some perverse form of mourning. Next to our messages of consolation sit mountains of distraction, clicks away from invites, messages, and notifications that encourage us to make quick, efficient work of what once took intentionality. And why?</p>

<p>Because our massive volume of “relationships” make us believe we need digital methods to manage our infinitely growing network of friends.</p>

<h2>A simple equation.</h2>

<p>If you have a thousand friends on Facebook, how often do you think something bad happens to them? Once a year? If that’s the case, then on average, you will have more than two negative things on your feed every day. </p>

<p>And because bad news is viral, you’re fairly likely to see bad news every day on Facebook, if you visit Facebook every day.</p>

<p>Depending on the definition of “bad things”, this number could be wildly more (or perhaps significantly less), but it’s far more than if you were to sample, say, 150 people.</p>

<p>And that number happens to be a proposed number of people we can cognitively maintain meaningful relationships with. It’s called <a href="http://en.wikipedia.org/wiki/Dunbar's_number">Dunbar’s number</a>.</p>

<h2>Meaningful Relationships</h2>

<p>Your past is nothing to necessarily throw away. Don’t get me wrong, I love the people in my past.</p>

<p>However, I am responsible primarily for my present and my future. When my past stands in the way of my present and my future, it’s time to cut something.</p>

<p>My <em>most meaningful relationships</em> are the ones I intend to cultivate in my present and my future. Expending energy to cultivate relationships that were primarily from my past (as in, I don’t talk to the person even on a yearly basis) should always take second seat to the relationships I’m cultivating now.</p>

<p>And here’s the kicker: if I’m reading the sad news about my long lost high school friend, I’m adopting anxiety at the expense of celebrating the good news from my <em>most meaningful relationships.</em></p>

<h2>A Culture of Permanence: Learning to Say Goodbye</h2>

<p>We live in a culture where everything is preservable (except snapchats). And why not? It’s supported by zeroes and ones, so anything is possible.</p>

<p>The problem is, our human brains are not computers; we can’t expand our cognitive ability to retain meaningful relationships. And as we’ve said before, putting energy into our least meaningful relationships takes energy away from our most meaningful relationships. And quite often, this energy is spent consoling and listening to patently bad news.</p>

<p>So the answer? Say goodbye. Cut yourself off from your past. Do so with very specific intentionality, understanding that you will love and live better with the people you care about most. Don’t spread yourself thin and risk living in a constant state of depression and distant relationship; instead, live and breathe deeply with those you are closest with.</p>


The Terror of Facebook and the Endless Social Network


<h1>I want you to steal these ideas.</h1>

<p>Seriously. Make these things a reality.</p>

<p>There have been a LOT of people who have said this in recent years: ideas are relatively of no value. Until someone actually executes and makes them valuable, ideas are about as value-less as dreams.</p>

<p>Okay, sure - the genesis of creativity is an idea. But that doesn’t mean the idea is the thing of value.</p>

<p>For the sake of brevity, I’m going to go ahead and post some ideas here that I have discussed recently, and I will continue to post more ideas in the future. The hope is that someone will take these ideas and execute; I certainly can’t do all of them.</p>

<p>So, my only request is that if you are inspired by these ideas (even if you don’t execute them directly), contact me and let me know. You can find me easily. Google “Jonathan Cutrell”.</p>

<p>Without further ado:</p>

<h2>Coffee subscription drive-thru service</h2>

<em>Credit actually is due to <a href="http://twitter.com/taylorleejones">@taylorleejones</a> for most of this one</em>.

<p>Coffee is one thing almost everyone I know has in common. So much so that many of us have a coffee budget that we write off on our taxes. Subscriptions simplify our lives to a great extent. The idea is simple: create a subscription service that takes advantage of passive Bluetooth at a drive-thru and provides a reliably great cup of coffee any time I want it (24 hours). Heck, you could create learning algorithms to do auto-ordering and preparations schedules. I just want my same coffee, and I want it to be good. And I’d love data on my coffee drinking habits (because I’m a part-time data nerd).</p>

<p>Make sure the coffee is awesome. On the flip side, make it cheap, too. You’re clearly going to trade personal data (think iBeacons) for coffee. Luckily, coffee IS cheap, especially in bulk, so don’t worry about the margins. They’d be silly good, especially if you leverage that aforementioned data well. If people come by who don’t have a subscription, just charge them a flat fee for a cup. Then at the very least, you likely have a viable drive-thru service.</p>

<h2>On-Demand Task Service (Crowd-sourced)</h2>

<p>TaskRabbit is awesome. But it doesn’t take advantage of the ultimate scalability model that Craigslist, Ebay, AirBnB, Kickstarter, etc have captured over the years: the crowd is more powerful than the individual. So build a thing that connects people (people means ANYONE) who need something done now and are willing to pay for it with the people (anyone) who are willing to do that thing. </p>

<p>How does it make money? Be the payment service, too. You should easily be able to complete a task and both parties press a button to get paid. Every time someone gets paid, you do too. Make the un-scalable part provide monetary value: vetting. Allow people to pay to become “verified.”</p>

<h2>Scaled Micro-Investment for the Financially Clueless Laymen</h2>

<p>I know almost nothing about investment.</p>

<p>There, I said it.</p>

<p>Perhaps this is because I’ve never received investment money myself, so I’ve never been pressured to learn.</p>

<p><em>But I do want to invest.</em> Not a lot - just a bit of my money that would otherwise go into savings. And I don’t want to go and meet with a broker, nor do I want to learn everything about stock trading. And honestly, I want to invest in very early stage companies, not huge national corporations.</p>

<p><em>I bet there are more people like me.</em> Probably a LOT more people like me. And the truth is, <strong>we have MONEY that we want to INVEST</strong> in awesome things.</p>

<p>Not donate - invest.</p>

<p>Not pre-order a product - invest.</p>

<p>(In a dream world, I would also receive tiny bits of equity for these tiny investments.)</p>

<p>Build an iPhone app that lets me throw a thousand dollars at a private startup doing something awesome, and pays me just a little bit when they succeed. I understand everything I need to understand to make a bet. Let me make a bet. (And you take some of that money, by the way.) Make it like Monopoly instead of business school.</p>

<h2>Personal Privacy Intelligence, Automated</h2>

<p>Want to know who is looking at your stuff, where they are, and what they want? If you don’t already, you probably will. Alexis Ohanian (yes, I mention him a lot right now) relates people invading our data to someone opening our mailbox and reading our mail. Yes, I absolutely want to know exactly where the packets of information are traveling, and who opens them. If you create a startup that tells me with some level of confidence where my data is and what is being read, when, by whom, I would pay a body part.</p>

This has significant business implications too; think Google Analytics on steroids, plus a private investigator in the form of intelligent algorithms and tracking techniques. The privacy war is coming, and there’s a lot of money in war. If someone is spying on me, I also want to spy on them. This has a lot of physical-world cost in the long run, but whoever owns this will probably own it for a long time. They can also be sure that they will receive a lot of resistance and shutdown requests, so it’s probably wise to do this in a country where the government is… small.

<h2>A REAL, widely accepted solution to this:</h2>

<a href="http://img.svbtle.com/crjckw4d9b4hma.jpg"><img src="https://d23f6h5jpj26xu.cloudfront.net/crjckw4d9b4hma_small.jpg" alt="convoluted_mess.jpg" /></a>
<a href="http://img.svbtle.com/3vvrvr9xtipruw.jpg"><img src="https://d23f6h5jpj26xu.cloudfront.net/3vvrvr9xtipruw_small.jpg" alt="remotes.jpg"/></a>

But seriously, how is this not completely done yet? I know the XBox One is heading this direction, but how close is it? I’ll answer your question with a question: when will my Dad buy an XBox One? Now, provide a simple, beautiful solution to the problem of discrete boxes doing discrete things that can benefit from all of the automation and remote-ness (read: not remote control) of the cloud. Give me a way to schedule EVERYTHING.

<p>Give me a way to throw away Comcast’s horrible channel surfing interface. I still want the things cable provides me, like reliable sports - but please, for the love of God, make things look better than TiVo circa 1999. FIFTEEN YEARS, guys. And if you think your one Raspberry Pi with XBMC is enough, then you probably don’t watch sports. And you’re probably not willing to keep paying for cable and Netflix, but I am. Someone make a Nest for my home entertainment system, and I’ll buy. Now, do a deal with cable companies and/or Netflix to be the single solution for any home, and you win the long term game.</p>

<h2>Appified Personal Article Insurance</h2>

<p>I came up with this idea recently when the apartments around mine started having pipes burst, destroying a good bit of their stuff. Let me ask you this: did you update your homeowners or renter’s insurance right after the holiday influx of new Christmas toys? No? Why not? Certainly not because you don’t want to pay to protect your stuff. It’s about the inconvenience of the call to the insurance agent. If only there was a way to take a picture of your stuff and find it in a database, and update your policy to cover your stuff…</p>

<p>I, and many others, would LOVE to add 10 cents instantly to my renter’s insurance whenever I get something new that I’d like to protect. Oh, and by the way - think about the ENORMOUS potential of having the data of peoples' belongings indexed. Give them deals in a trade for their stuff, and ad revenues would be stupid good.</p>

<p>Oh, you have a collection of president bobbleheads? Looks like your missing <a href="http://shop.history.com/detail.php?p=368569&amp;ecid=5511&amp;pa=CSE-FGL&amp;CAWELAID=1226685247&amp;catargetid=120015750000005397&amp;cadevice=%7Bdevice%7D&amp;cagpspn=pla&amp;gclid=CJX01LH3lLwCFYNi7AodJy8AOw">George W</a>. Throw that in your cart, and we’ll auto insure it for less than 2c a month.</p>

<p>Seriously, why isn’t this a thing already? (I didn’t say all of my ideas were ethically good… they just would make money. For the record, I’d totally use this, but I bet a lot of people hate the thought of it.)</p>

<h2>Job Hunting Meets Matchmaking</h2>

<p>LinkedIn sucks at this, let’s be honest. Sure, it has a pretty decent connection-map for your professional relationships, but have you ever tried to hire on LinkedIn? It’s terrible. And really, there doesn’t seem to be a GREAT solution to the recruiting problem. Maybe that’s short-sighted, but the existing solutions are either old school (phone calls and vague recruiting emails) or are so chock full of horrible fits and spam and people who don’t maintain their portfolios.</p>

<p>Take a cue from high-end dating websites. People who want to get hired will probably pay to put their profile on a curated site dedicated purely to hire matchmaking. If you’re hiring, wouldn’t you love to use a serious matchmaking site for your search to find someone who fits your culture, needs, and budget? Give space to both the hirable people and the hiring people to do the seeking. Develop matchmaking algorithms for personality and job placement. Be vigorous to keep recruiters out, or at least very accountable to not be spammy. Focus on happiness/genuineness and job quality first, money second, and skills third. To jumpstart this effort, make it happen in a niche. Be the ultimate job placement software as a service in the restaurant management market of the southeastern United States.</p>

<p>This is one of hopefully many installments. If you want to take any one of these ideas, like I said, just let me know and then go full-steam ahead. I would want you to succeed, because I would use every one of these things if it was done right.</p>

<p><a href="https://news.ycombinator.com/item?id=7110810">Discuss on HN</a></p>


Steal these Startup Ideas: Collection One


## <u>A chance to surprise and delight someone by doing something a little exceptional goes a long way because it provides a smack of awesome humanity upside the head.</u> - Alexis Ohanian [1]

<p>Bill Murray has a reputation. Sure, to many he is an actor with a strong and highly memorable personality in each of his movies. But Bill Murray’s fame goes deeper.</p>

<p>If you have had the chance to experience what I’m talking about here, I’m certain you would agree: Bill Murray is a delightful person.</p>

<p>We know the norm for the famous population amongst us is to show up almost exclusively with “their kind”, highly guarded from much personal interaction with their fans.</p>

<p>Bill Murray has quite an opposite approach to this mindset. On <a href="http://www.telegraph.co.uk/news/uknews/1531473/Bill-Murray-turns-fiction-into-fact.html">occasion</a>, Murray shows up in an unexpected place and acts in unexpected ways. These stories have become somewhat mythical, enough that people have adopted a practice of telling these stories, even if they never even happened.</p>

<p>What’s the big deal? Who cares that Bill Murray did something <em>ordinary</em>?</p>

<p>Well, the answer is quite simply that for Bill Murray, that ordinary thing was out of the ordinary. And not in the crazy Kanye-interruption kind of out of the ordinary, but rather in the “I’m going to give you a car for no good reason” kind. Bill Murray becomes what other actors won’t: a real life human being, doing real life things. What a delightful surprise indeed.</p>

<h2>Ordinary Actions Aren’t Always Ordinary</h2>

<p>A friend of mine once sent an email to Steve Jobs. If you have read anything about Jobs, you’ll know that he, on occasion, would send short (as in single-sentence) replies to random emails that hit his inbox.</p>

<p>What’s the big deal? Why does anyone care?</p>

<p>Because it’s out of the ordinary. It’s almost like winning the lottery in some sense - out of the seeming millions of emails that hit Steve’s inbox, he picked yours to respond to.</p>

<p>That email - a normal, ordinary thing - now hangs framed next to my friend’s desk to remind him every day what customer service looks like.</p>

<p>Steve knew his customer’s context. He knew his fans, and he knew what gets good press. He knew that the experience of seeing “Sent from my iPhone” tagged on an email from him would mean the world to someone, and yet it only took a few seconds for him. He knew that keeping the emails short actually added to the experience, to the lore: “and then he responded with a simple yes” sounds much more like the cold, in-the-elevator-firing Steve than “and then he responded.”</p>

<h2>It’s not about fame.</h2>

<p>Of course, fame gives you a much larger platform. Like a newborn baby learning how to walk, if you’re famous, people fawn over every little thing you do. So, when a famous person does something out of the ordinary, it is elevated. But it doesn’t require fame to surprise and delight people.</p>

<p>What it requires is context and personal connection.</p>

<p>In the early years of Reddit, Alexis Ohanian surprised and delighted authors whose posts hit #1 on Reddit with a digital golden alien email sent personally from him. Reddit hadn’t hit superfamous status, and yet this quirky, personal email elevated Ohanian in these authors' minds.</p>

<p>Photojojo created a simple interface enhancement that gives users a small bit of shock: <a href="http://brooksbell.com/blog/2011/10/dont-tell-me-what-i-cant-do-how-photojojo-uses-rule-breaking-to-increase-engagement">pulling a lever unleashes the arm of a cartoon monster on the page</a>. Kickstarter’s footer lets you cut the bottom off, revealing the message “Eureka! You’ve found 
our little secret.”, and inviting the discoverer to subscribe to their mailing list.</p>

<h2>What does surprise and delight look like?</h2>

<p>It really seems simple: do something outside of the expected behavior that will make someone smile. Take the routine out of what your users experience, and instead give them something dynamic and unpredictable. Provide a random, good (and perhaps even undeserved) customer service experience. Give things away on occasion for no reason, and chalk it up to PR investment. Make individual customers feel special just for being around.</p>

<h2>Whatever you do, don’t fake it.</h2>

<p>If you fake it, people will know. Don’t send out mass emails that attempt to make people feel individually noticed. Instead, let them know it is a mass email; this communicates that you respect their right to filter emails based on personal importance. Don’t provide something for free with stipulations. Don’t go halfway with these things; if you are going to surprise and delight your customers, you actually have to care primarily about surprising and delighting them, and secondarily about the effect that will have on your business. This isn’t business 101, where profits are the only thing that counts; this is about human intuition. If all you care about is money, you can wrap that in as many compliments as you want - I will eventually feel the weight of your fakeness. Cultivate real care for your customers, their problems, and their joys.</p>

<p>[1]Alexis Ohanian. Without Their Permission: How the 21st Century Will Be Made, Not Managed (Kindle Locations 1174-1175). Grand Central Publishing.</p>

<p><a href="https://news.ycombinator.com/item?id=7060287">Discussion on Hacker News</a></p>


The Anatomy of Surprise and Delight

<p>I recently encountered a demeanor that I couldn’t quite place. I anonymously overheard a conversation and, unfortunately, let it get under my skin enough to tell you about it.</p>

<p>I (somewhat ashamedly) tried to find some kind of a meme that described the person who portrayed this demeanor, which forced me to put it into words: nonchalant arrogance.</p>

<p>The “yeah, it’s a big deal, but I know you’re going to think it is, so instead of aligning with you, I’m going to downplay my accomplishment so you think it’s the tip of my intellectual iceberg” attitude.</p>

<p>The “if you like that, there’s more where that came from, but I’m under an NDA” guy.</p>

<p>The “eh, their third album is okay, but the early stuff you don’t have access to is the best” attitude.</p>

<p>I’m not sure why this attitude is still somehow effective in shifting perception, but it is. Perhaps it has something to do with a perceived sense of humility from the general audience, or maybe it portrays some kind of rare, cultured superiority and curation of “good ideas” that should be followed, like a good Instagram-er. Like the guy who turns his nose up at certain kinds of wine if they are paired with the wrong kinds of food, but gets a column in the paper as an expert sommelier.</p>

<p>I hate it, and I don’t want to be it, but at the same time I <em>do</em> want to communicate a sense of intellectual superiority. (For those of you who <u>don’t want to be perceived as smart,</u> throw the first stone.) I want others to value my opinion at a level of excellence.</p>

<p>The difference is, I don’t want it to be because I have some exclusive access to information that they don’t have; rather, that I have done the hard work to uncover that information, and that access is granted only to those who sweat for it.</p>

<p>So I have this struggle, as many others might, that I don’t have enough knowledge to properly and fully convey an idea. Certainly I feel confident in my vocabulary and in my writing style, and I truly don’t experience writer’s block very often. What I do experience is a sense of fear that once I write something out, or build something to release, that it’s going to be subpar. It’s going to be like the band’s 3rd album, or a badly paired wine.</p>

<p>I refuse to adopt nonchalant arrogance. If I am proud of something I’ve done, I’m not going to put on a charade of humility in hopes of you noticing - I’m going to tell you how excited I am, and show you my project. Who knows if you will like it. From my point of view, honesty and transparency are just as valuable as humility. I’m not above my own work. I’m certainly not above my own writing, or the subjects I write about. Nor am I above building for the web, or the people for which I build. I love what I do, and I’m really quite excited to tell you about it, especially if you have an open ear.</p>

<p>I vow never to post with a contrived ironic space between myself the creator, and my creation. I want my fingerprints all over my creations.</p>

<p>The chase for the external perception of intellect can be a dangerous path. That chase leads us to stop being excited when we learn something new. Do you remember when you first made a successful jQuery transition, or when you first learned how to remove something from a picture in Photoshop? The love for the work often dies when you chase a sense of intellect in hopes of an elevated position in the field. You can easily lose respect for the joys and simple highs of your craft. You begin to see the seemingly trivial nature of what once kept you up late at night, reading and hacking and intoxicated with hope of building something of personal value to show the world.</p>

<p>As Alexis Ohanian says in his book <u>Without Their Permission</u> and in the video below, I want everyone who comes into contact with me to know that I “give lots of damns.” That as a creator, I don’t want to separate myself from the work that I do for the sake of perception. I want the things I create to be so closely tied to me as a person that I fight for them like they’re a living, breathing extension of myself.</p>

<iframe width="520" height="390" src="//www.youtube.com/embed/o0a-sUxpbYU" frameborder="0" allowfullscreen="true"></iframe>


Nonchalant Arrogance, Intellect, and Caring About Your Work


<p>I have a lot of different responsibilities on a day-to-day basis. I’m guessing you probably do too.</p>

<p>Family and home responsibilities, like loving my wife, paying bills, and taking my dog on walks.</p>

<p>Personal responsibilities like sleeping enough, exercising, chasing my own goals, and making time for intentional sanity.</p>

<p>Work responsibilities - now there’s a big (and awesome) list. In particular, let me highlight two types of work I do, at work.</p>

- <em>Reactive work</em> - work that requires me to respond to external resources, like emails, phone calls, meetings, etcetera
- <em>Creative work</em> - work that requires me to build something out of nothing (or out of a predetermined specification)

<p>As a company, Whiteboard employees recently read 99U’s <a href="http://www.amazon.com/Manage-Your-Day-Day-Creative/dp/1477800670">Managing Your Day to Day</a>, an excellent book about building an effective creative routine. We’ve all adopted a good number of practices proscribed in the book to start out the year, and let me tell you, it has been fantastic. A few simple thoughts on these practices, as they will inform what this article is really about.</p>

<h2>Don’t check email, social media, or content sources until 2PM or later.</h2>

<p>Note that this is making space for the creative work, where nothing is needed. Quite a few successful creative folks agree that it’s best to do this kind of work in the morning, so we’re trying it. The basic concept is to avoid getting into response mode, as we tend to allow problems and tensions to linger, but instead to start our day out with a <a href="http://www.nytimes.com/2014/01/12/opinion/sunday/goodnight-sleep-clean.html">clean brain after sleep</a>, which will theoretically encourage what Cal Newport calls <a href="http://calnewport.com/blog/2012/11/21/knowledge-workers-are-bad-at-working-and-heres-what-to-do-about-it/">deep work</a>.</p>

<h2>Maintain a stopping point.</h2>

<p>At some point during the day, your routine needs to shift away from working and onto the other parts of your life, like hiking or relaxing or basket weaving. This allows for you to not only fulfill your family and personal responsibilities and/or projects, but also forces you to do only the most important things for projects while you are working on a day to day basis.</p>

<h1>Learn this: The rest of the world is not on your schedule.</h1>

<p>With these two thoughts in mind, we must also realize that the rest of the world isn’t on our schedule. So, emails will come in at night. (Ignore them until 2PM the next day.) People around the world will continue to live their schedules, and in fact even in the United States, people on one coast will have a different schedule than I will.</p>

<p>So, in a very narrow sense, people are asynchronous from one another.</p>

<p>Before you continue, if you think social media is useless, then you can stop here and hopefully still gain something from the article. No one else needs to hear why you’re quitting Twitter and Facebook and throwing your phone away and selling your car and moving out to the back woods to get away from the noise in the world. (You already told us… on Twitter and Facebook.)</p>

<p>If you take social media to be important to your job (it is for mine) or for your personal aspirations (again, it is for mine), then you should understand that schedule is everything.</p>

<h2>Why does schedule matter?</h2>

<p>First of all, professional engagement on social media isn’t about people wanting a glimpse into your life. (Unless, of course, they are particularly interested in your personal affairs. Generally not the case for me, other than my mother.) Instead, it is about what your followers can gain from you.</p>

<p>What we have to understand is that our followers don’t gain anything from us if they don’t see relevant content, but content isn’t enough on it’s own; it must also be <u>timed well</u>.</p>

<p>Open your Twitter timeline, and leave it for 20 minutes. I can almost guarantee, unless you follow a small number of people, that tweets from 20 minutes ago have effectively been buried in those 20 minutes.</p>

<p>So imagine that your next opportunity could come from a Twitter follower who is 4 hours separated from you, time-zone wise. How can you engage with this person in a meaningful way?</p>

<p>As far as social media goes, the answer is to <u>post whenever they are looking</u>.</p>

<p>This has absolutely nothing to do with my segmented work schedule; no one cares that I’m not posting to social media until after 2 PM except my family and my coworkers.</p>

<p>So how do I maintain my sane, segmented daily schedule while also increasing my chances of meaningful engagement on Twitter?</p>

<h2>A good answer: Buffer (or a similar tool).</h2>

<p><a href="http://bufferapp.com">Buffer</a> is a tool that allows you to setup a regular tweeting schedule. You fill up your queue however you see fit, and let Buffer auto-tweet for you. And here’s the kicker:</p>

<p><em>All of your content discovery and sharing can be done in a single block of your day.</em></p>

<p>Let me rephrase:</p>

<p><em>You can now engage with social media asynchronously instead of treating it like a chat room.</em></p>

<p>Let me re-rephrase:</p>

<p><em>You can now have a constant presence on Twitter without inundating your followers and sucking your time away from other (more) important things.</em></p>

<p>If you aren’t getting how this can be insanely valuable if done properly, then you probably need to try it for a while to learn.</p>

<h2>A challenge.</h2>

<p>Use a tool like Buffer to write your posts and share content for a limited, concentrated block in a day. Experience the peace of limiting social media distraction throughout your day, and the benefit of increasing intentionality and regularity of your online presence as a result of smarter computing.</p>

<p>(Disclaimer: I’m in no way affiliated with Buffer, nor do I receive any benefit for touting their service, but it is in my opinion the prettiest and generally the most popular tool for this particular use case. If I’m missing the mark here, please let me know.)</p>


I’m Using Buffer to Segment My Working Day, and it’s Awesome

<p>What will you do when you have the opportunity to trade your privacy as a currency?</p>

<p>Of course, it’s not a sustainable model, but that’s not the point. The point is that as long as we can trade our info for goods and services, we will set new standards for technological boundaries on our lives. And we’ve already seen it coming fast - mobility has been tackled, wearability is next, and embedded/environmentally ubiquitous will come after.</p>

<p>Apple released a phone that knows you by the same way you are identified by if you commit a crime or two. (This is a gross over-generalization, but stick with me.) On the flip-side (read: not the private sector) the NSA can listen in on your conversations. Without a warrant. Endorsed by the president. <a href="http://www.nytimes.com/2013/12/22/us/white-house-tries-to-prevent-judge-from-ruling-on-surveillance-efforts.html?_r=1&amp;">He doesn’t really want a call made on whether that’s okay.</a></p>

<p>And what will this bring? With movies like The Fifth Estate coming into mainstream (albeit fairly unsuccessfully) and with technological literacy being pushed with efforts to get <em>everyone to code</em>, there will eventually be a <strong>click</strong> moment where people understand the seriousness of the NSA’s deal to weaken RSA. Eventually there will be an enlightenment of what “surveillance state” means as it relates to all of these wearable devices and Xbox eyes and webcams and…</p>

<p>We’ve heard about Luddites, and I think this may be their birthplace: a strong, deep-rooted hatred for the corruption and terror of privacy-destroying devices like Apple’s iPhone 6. They reject the need for technology, first as a hipster trend (like leaving Facebook), but evolving into a real movement.</p>

<p>Obviously this is absurdist in many ways. (At least hopefully that’s obvious.) The truth is, the general population will take longer to shift to technological literacy enough to understand the <a href="http://www.theguardian.com/world/2013/dec/20/nsa-internet-security-rsa-secret-10m-encryption">seriousness of the RSA deal</a>. (By the time that click moment happens, RSA will have become obsolete anyway.) But the underlying pattern is emerging: people will start caring more about privacy than ever before. They will understand that their need to be “always-connected” puts that privacy up for crucifixion, and that creates a direct conflict with the rapidly advancing personal device world. And that will be the war of privacy.</p>


The war of privacy is coming in 2014


<p><strong>tldr;</strong> When adopting tools, do so to eliminate waste. It’s not worth adopting a tool for the sake of the clout of adopting it. For development, automate things you do the same often (or should/could do the same often). Build shareable processes that require little training overhead. Identify pieces of your process that require a common language; these places are usually where tools can be introduced to solidify that common language.</p>

<h2>Don’t mess with my flow.</h2>

<p>If you are a leader of a development team, you know that it can be hard to adopt any team-wide change in workflow. This is especially true if the new project tools are a significant shift away from the way you already work. The truth is, the overhead of managing the tools (instead of working on the project itself) can bog down your team, make for some confusion, and ultimately cause over-engineering and waste of time.</p>

<p>But the truth is, the evolving tools of web design are rising for a reason. Dependency management tools (or any kind of tool, for that matter) that are rising in fame should be evaluated. But where is the line? How can you know when its time to bite the bullet, buckle down, and learn the details of these tools? I think the answer is ultimately subjective, but I’ll share an anecdote with you about how we decided to move our team to a shared workflow that involves dependency management through Grunt, GitHub-centric code control, etcetera, while generally avoiding overhead.</p>

<h2>A Note About Dependency Management</h2>

<p>The goal of dependency management is to abstract away the details of manually managing toolsets that a project uses. In the Rails world, this is done in a <code>Gemfile</code>. In Node, it’s in a <code>package.json</code> file. Almost every project has some kind of dependency; it’s your job as a developer to make sure the dependencies are met in a suitable fashion. Furthermore, every project has different “build processes” - for some, this means compiling code. For others, this means setting environment variables or incrementing a “revision” count. Grunt is a highly-configurable tool that does many of these things for web-based projects. Powered by Node.js, Grunt and related projects have gained an enormous amount of support and active development contributions.</p>

<p>At Whiteboard, we are constantly starting new projects. This can happen even on a daily basis. What’s more, the developers are constantly iterating on and reviewing projects. Our work is highly communication-centric, with a focus primarily on a consumption orientation that is driven to develop brand voice. That’s a long way of saying we work more heavily with content publishing platforms than we do “web apps”.</p>

<p>For this reason, we adopted Wordpress long ago as our primary project platform, and have made Wordpress knowledge a core competency of our agency. We work in other areas (Rails, specifically) as well, but for spinning up a content publishing platform for a client, Wordpress is our go-to.</p>

<h2>Manual Dependency Management</h2>

<p>A year ago, our processes were very slim. I like to think of this as a Good Thing™. We worked quickly, and used tools as they popped up. In the Wordpress world, we found a few base themes (like <a href="http://themble.com/bones/">Bones</a>), and then threw our own self-brewed stuff on top. The development team is experienced enough to adopt a wide variety of tools, and this worked fine. But we started to notice problems creeping into our system: our tools were all <em>quite similar</em> amongst a set of projects, but none of them were dependably exactly the same. We also knew that the tools <em>could</em> be unified - we used the same basic types of tools/libraries/themes/structure on every single project.</p>

<p>We had adopted LESS, but were using CodeKit on our private machines without any global configuration. (CodeKit is awesome, and has these types of project-level options available, but we weren’t using them.) After a few accidental overwrites and other issues, we realized that everyone’s process, like our toolsets, were very similar, but just off enough to show cracks in our system.</p>

<h2>Makefiles</h2>

<p>Our first step towards a solution was to adopt a Bootstrap-inspired approach to compilation and project builds. Before Bootstrap 3, the process for compiling assets primarily revolved around a Makefile. We brewed up our own makefile, and created the first version of a theme we called Launchframe. This unified a lot of our tools, and immediately this increased our ability to communicate about projects to one another, without much hassle. The powerful element here is that our code started looking and feeling exactly the same (rather than relatively the same). We also all adopted native (Mac OS)AMP + phpMyAdmin stacks on our Mac OS machines, using Homebrew to get everything installed. This makes for predictable and very easily executable PHP-based projects. (There are quite a few guides for how to do this, including <a href="http://vanbosse.be/blog/detail/a-homebrew-lamp-stack">this Homebrew-specific one</a>.)</p>

<h2>Moving to Grunt</h2>

<p>The Makefile approach eventually started showing its flaws. Most specifically, some of the error reporting and watch scripts didn’t quite work as expected. While Make is certainly a powerful way to handle problems, we realized that people in our field were handling these same problems in a much more actively supported way through Grunt (and associated CLI tools). When Bootstrap 3 moved to Grunt, we made the move to Grunt, and once again adopted a lot of the techniques in the Bootstrap build process.</p>

<h2>The Trick</h2>

<p>The best way to reduce overhead for any kind of development process is to first <em>find your consistencies and near-consistencies</em>, and commit to them. Once you’ve made this commitment, build your tools to automate these consistencies. For us, we always use jQuery, we always use LESS, we always start with our base theme, and we always use a particular file structure. To make the process as easy as possible, we chose to commit to these consistencies, and build our workflow so that our developers need to only know the basic overview of the process. To start a new project at Whiteboard, you install Wordpress, change into that directory and type <code>npm install</code>. This will install all dependencies for the Grunt tasks to work properly. Then, run grunt watch. Develop on the project like you always do, and push live.</p>

<h2>A Step Further</h2>

<p>Who wants to install Wordpress? Wouldn’t it be nice if we could automate the whole process from front to back, and have a few prompts with configuration options along the way? Of course it would. So I made this script. Running this on a configured machine with the right tools does everything to open up the project, watching and ready to be edited. It’s also a lot of fun to run it, considering the colors <code>lolcat</code> provides. :) It utilizes a few tools here and there, particularly <code>wpcli</code>, to get things going. This could probably be grunt-ified, but ask yourself: why would that be valuable?</p>

```
#!/bin/bash
command -v lolcat &gt;/dev/null 2&gt;&amp;1 || { echo &gt;&amp;2 "I require lolcat but it's not installed. Run gem install lolcat."; exit 1; }
command -v wp &gt;/dev/null 2&gt;&amp;1 || { echo &gt;&amp;2 "I require Wordpress CLI but it's not installed. ,\n Run the following:,\n curl https://raw.github.com/wp-cli/wp-cli.github.com/master/installer.sh | bash
."; exit 1; }
command -v git &gt;/dev/null 2&gt;&amp;1 || { echo &gt;&amp;2 "I require git. For more information, visit: http://git-scm.com/book/en/Getting-Started-Installing-Git "; exit 1; }

purple='\x1B[0;35m'
NC='\x1B[0m' # No Color


echo '

LAUNCHFRAME 0.1 #########
####### A WHITEBOARD TOOL

       !
       !
       ^
      / \
     /___\
    |=   =|
    |     |
    |     |
    |     |
    |     |
    |     |
    |     |
    |     |
    |     |
    |     |
   /|##|##|\
  / |##|##| \
 /  |##|##|  \
|  / ^ | ^ \  |
| /  ( | )  \ |
|/   ( | )   \|
    ((   ))
   ((  :  ))
   ((  :  ))
    ((   ))
     (( ))
      ( )
       .
       .
       .
' | lolcat

if [[ $1 == "" ]]; then
    read -p "Enter the site folder you want to create for installation: " sitefolder
else
    sitefolder=$1
fi

echo -e "${purple}Downloading Wordpress... Please wait a moment.${NC}"

mkdir -p "${sitefolder}" &amp;&amp; cd "${sitefolder}"

wp core download

echo -n "Enter database name (press enter for wp_${sitefolder}) "
read dbname
if [[ $dbname == "" ]]; then
    dbname="wp_$sitefolder"
fi

echo -n "Enter database username (press enter for root) "
read dbuser
if [[ $dbuser == "" ]]; then
    dbuser="root"
fi
read -p "Enter database password (required): " dbpass
while [[ $dbpass = "" ]]; do
    read -p "You cannot continue without entering a database password (required): " dbpass
done

echo -n "Enter site url (press enter for http://localhost/${sitefolder}) "
read siteurl
if [[ $siteurl == "" ]]; then
    siteurl="http://localhost/${sitefolder}"
fi

echo -n "Enter site title (press enter for ${sitefolder}) "
read sitetitle
if [[ $sitetitle == "" ]]; then
    sitetitle="${sitefolder}"
fi
echo -n "Enter admin email (press enter for admin@example.com) "
read adminemail
if [[ $adminemail == "" ]]; then
    adminemail="admin@example.com"
fi

echo -e ",\n"
echo -e "${purple}Creating the wp-config file.${NC}"
echo -e ",\n"

wp core config --dbname=$dbname --dbuser=$dbuser --dbpass=$dbpass

echo -e ",\n"
echo -e "${purple}Creating the database.${NC}"
echo -e ",\n"

adminpw='[filtered]'
adminun='admin'
wp db create
wp core install --url=$siteurl --title=$sitetitle --admin_name=$adminun --admin_password=$adminpw --admin_email="$adminemail"

echo -n "Install Multiple Post Thumbnails? (y/N) "
read a
if [[ ${a:0:1} == "Y" || ${a:0:1} == "y" ]]; then
    wp plugin install multiple-post-thumbnails
    wp plugin activate multiple-post-thumbnails
else
    echo -e ",\n"
    echo -e "${purple}Run wp plugin install multiple-post-thumbnails to install later.${NC}"
    echo -e ",\n"
fi

echo -n "Install Yoast SEO? (y/N)"
read a
if [[ ${a:0:1} == "Y" || ${a:0:1} == "y" ]]; then
    wp plugin install wordpress-seo
    wp plugin activate wordpress-seo
else
    echo -e ",\n"
    echo -e "${purple}Run wp plugin install wordpress-seo to install later.${NC}"
    echo -e ",\n"
fi

echo -e ",\n"
echo -e "${purple}Downloading Launchframe...${NC}"
echo -e ",\n"

wp theme install https://github.com/Whiteboard/launchframe/archive/master.zip

echo -e ",\n"
echo -e "${purple}Activating Launchframe...${NC}"
echo -e ",\n"

mv wp-content/themes/launchframe-master wp-content/themes/launchframe
wp theme activate launchframe
echo -n "Install Custom Meta Boxes? (y/N)"
read a
if [[ ${a:0:1} == "Y" || ${a:0:1} == "y" ]]; then
  git clone git@github.com:jaredatch/Custom-Metaboxes-and-Fields-for-WordPress.git wp-content/themes/launchframe/inc/cmb
  echo "Custom Meta Boxes requires a manual include and setup - be sure to add this in functions.php or somewhere similar."
fi

cd wp-content/themes/launchframe
npm install


echo -e ",\n"
echo -e "${purple}Opening the site install...${NC}"
echo -e ",\n"

open $siteurl

echo "Done!"
echo '
  ______   _______  _______  _______  _______
(  ___ \ (  ___  )(  ___  )(  ___  )(       )
| (   ) )| (   ) || (   ) || (   ) || () () |
| (__/ / | |   | || |   | || |   | || || || |
|  __ (  | |   | || |   | || |   | || |(_)| |
| (  \ \ | |   | || |   | || |   | || |   | |
| )___) )| (___) || (___) || (___) || )   ( |
|/ \___/ (_______)(_______)(_______)|/     \|


 ' | lolcat
subl ../../..
grunt watch
```

<h2>Do What Keeps You Moving</h2>

<p>The thing we’ve learned about learning new tools is to find ways of constantly doing something new. This means stop doing the same things over and over. Wasting your time doing the same things over and over means you aren’t innovating, and you aren’t creating change. Don’t stop learning, but learn, implement, and move on to learning more and doing more. This is perhaps an opinionated understanding of the purpose of learning as it applies to development, but it certainly offers a strong method for balancing intellectual progress and business-oriented productivity.</p>


How We Adopted an Agency-wide Grunt Workflow


<p>The quantified self is really quite a hot topic. Ivan Kirigin talks about it in his post <a href="http://blog.kirigin.com/personal-analytics">here</a> as a potential startup idea. I’ve created something simple I’d like to share with all of you.</p>

<p>It is really quite simple, but also very flexible. Before I explain what it is, I’ll cover some of the conceptual reasoning behind the solution.</p>

<p>I believe that to do lists are generally quite hard to deal with, and overall don’t help my productivity. They require me to return to them over and over throughout the day, managing them, and often only serve as a place to mark things as done (rather than a place to ensure that I am being productive).</p>

<p>However, I don’t mind prompts. I don’t mind alerts. Certainly too many of irrelevant alerts can be annoying. But if I am motivated to use the alerts, I will.</p>

<p>As a developer, I am used to constant feedback. I am used to my machine telling me when I have compile errors. I’m used to having <u>reports</u>. These reports are what I take action on. To-do lists stay dormant until I put effort into them. The same can be said for calorie tracking applications. The same can be said for most tracking applications.</p>

<p>So, I created a small script to ask me a random question. I set up a YAML file to track my answers and the dates of my answers. I then created a simple plist file to load the script every 8 minutes via <code>launchctl</code>. This will give me about 50 data points per workday.</p>

<p>While they may be simple data points, and while the questions will repeat, the concept is simple: my computer asks me a question, and tracks my answer for me. My answers can be arbitrary; I also have two types of questions. One is directly actionable, the other is subjective. (“Tell your wife you love her.” vs “What have you eaten today?”)</p>

<p>Here is the Ruby code:</p>

```ruby
#!/Users/jonathancutrell/.rvm/rubies/ruby-2.0.0-p247/bin/ruby
require 'yaml'
y = YAML::load_file(File.join(__dir__, "stretchr.yml"))
if (rand(10).to_f/10.0).round == 1
    @msgs = y["msgs"]
    @msg = @msgs.sample
    ret = `osascript -e 'set question to display dialog "#{@msg}" buttons {"Nope", "Did it"}'`
    ans = ret.split(":")[1]
else
    @questions = y["questions"]
    @msg = @questions.sample
    ret=`osascript -e 'set question to display dialog "#{@msg}" default answer ""' -e 'text returned of result' 2&gt;/dev/null`
    ans = ret
end
@answers = y["answers"]
@answers[@msg] ||= []
@answers[@msg]&lt;&lt; [ ans, Time.now ]
File.open('stretchr.yml', 'w+') do |file|
  puts file.write(y.to_yaml)
end
```

<p>And here’s the yaml file.</p>

```
---
msgs:
- Stand up and stretch.
- Live healthy, think healthy
- Tell your wife you love her.
- Do something to show appreciation to your coworkers and employees.
- Text a family member.
- Value, now. Stop doing things that don't matter.
- Have you kissed your wife today?
questions:
- Is your desk clean?
- Have you had 10 minutes of quiet thinking time today?
- What word are you thinking of right now?
- Who was the last person you spoke to?
- Is Hacker News open?
- What are you building now for tomorrow?
- Text a family member.
- What have you eaten today?
- On a scale from 1 to 10, how energetic are you?
- On a scale from 1 to 10, how productive do you feel today?
- How many hours did you sleep last night?
answers: {}
```

<p>And finally the plist.</p>

```
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
&lt;plist version="1.0"&gt;
&lt;dict&gt;
    &lt;key&gt;Label&lt;/key&gt;
    &lt;string&gt;org.jcutrell.stretchr&lt;/string&gt;
    &lt;key&gt;ProgramArguments&lt;/key&gt;
    &lt;array&gt;
        &lt;string&gt;/Users/jonathancutrell/stretchr.sh&lt;/string&gt;
    &lt;/array&gt;
    &lt;key&gt;StartInterval&lt;/key&gt;
    &lt;integer&gt;480&lt;/integer&gt;
&lt;/dict&gt;
&lt;/plist&gt;
```

<p>Some of these you can clearly see come from personal goals. Some of them, though, are much more related to aggregating some sort of arbitrary data. Later, I hope to gain some kind of insights from this into very specific areas of my life.</p>

<p>Notice the name <code>stretchr.sh</code> - this was originally built to be a simple reminder to stand up and stretch at my desk. I would go hours on end without stretching simply because it wasn’t on my mind. So many things we should, could, and want to do go undone because we simply let them slip our mind. I’m interested to see how much of an impact these more consistent reminders will have.</p>

<p>It’s obviously very easy to add new data points. Of course, as you add more questions or imperative messages, it’s more likely that you will have more time between data points on average, assuming an even distribution of the random range generator over time.</p>

<p>It would be easy to take this YAML data somewhere else, like for instance to JSON to be fed into something like D3:</p>

```
require 'yaml'
require 'json'
y = YAML::load_file(File.join(__dir__, "stretchr.yml")) # I think this may be v&gt;=2.0
puts y.to_json
```

<p>Interested in doing something similar? Or interested in making this more than it is? Let me know. I’d love to let this grow.</p>


Blog