Please don’t misunderstand me, though. Code review is without a doubt beneficial, especially to someone prone to silly mistakes like me, and especially with a larger team. It just tends to slow as the team grows.

With the GitHub flow you branch for each thing you share for review. That’s great if there’s no delay between submitting a pull request and merging it, but if the review step includes any delay things get tricky. To make additional changes to the same code you have to branch from your branch and keep the new branch up to date with review feedback. As you build a complex tree of branches that gets pretty difficult to manage.

The inevitable result on most teams is to either avoid working on the same code or to submit large pull requests. But then, as the pull requests get larger, the review time slows even more and compounds the issue.

Jackson Gabbard’s post on Stacked Diffs blew my mind. It described a problem I was feeling every day but couldn’t put into words in terms of this review delay cycle. My main takeaway was that by controlling what I reveal to my peers about my work I can help them review my code more easily. To do so, I had to come up with a git workflow that enabled me to fully control my change history.

Unfortunately the GitHub flow is pretty ingrained at Abstract, and Gabbard’s post described a process that there was little likelihood of implementing on our team because it would require drastic changes. I needed a workflow that had the advantages of stacked diffs but without requiring a retool of our entire team. I needed a flow that only required me to retool myself.

After some thinking, here’s where I landed in terms of personal guidelines:

1. Work on master each day. My master branch is my master branch, not the team’s, and would typically operate a little ahead of our master branch on GitHub.
2. Never push my master branch, since that would break the rules our team operates under.
3. Cherry pick commits I make to a new pull request branch and push it up.
4. Use interactive rebase and amend commits as needed as I worked to keep my pull requests to a single initial commit when submitting for review.
5. Cherry pick additional commits onto pull request branches when changes are requested so that the history on the pull request makes sense for my peers.

I decided to make this change and started in earnest that day.

I fairly quickly realized I needed a command to see how far ahead of GitHub I was, which lead me to add an alias for a git unmerged command. That alias looked like this:

[alias]
unmerged = log master ^origin/master --no-merges --pretty=oneline --abbrev-commit

Pushing pull requests up was even trickier. That process looked like this:

git branch [name] origin/master --no-track
git checkout [name]
git cherry-pick [rev-to-add]
git push origin [name]
git checkout --force master
git branch -D [name]

After a few times doing that I wrote up a quick Go project to handle it. It’s available at commondream/tbgand makes it easier to install and work with. The project adds two commands:

• git unmerged shows commits on master that aren’t on the remote
• git share adds a commit to a remote branch

A Day in the Life

I’ll try to make this all clearer with an example.

My day starts with me wanting to work on some performance improvements, so I hop onto a the repo for that project and git pull --rebase to make sure I’m up to date.

To start on the performance improvements,  I work directly on master. I commit and immediately realize that I want to tweak the commit a bit, so I go ahead and rewrite the commit with git commit --amend.

Eventually the change is starting to pull on some  refactoring ideas, but the performance itself is improved, so I go ahead and decide to share where I’m at for review. To do that I run git share perf-improvements HEAD because I worked on a single branch the entire time. git share pushes the commit at HEAD up to a new remote branch named perf-improvements. I hop over to GitHub and create a pull request.

To start the refactor, I again just add the work to master. There’s no need to wait on review or start a new branch, even though I’m continuing to work on the same code.   Once it’s working I commit it to master and move on. At this point running git unmerged shows a commit for the performance work and another commit for the refactor. I don’t share this commit with the team yet, because reviews on the perf-improvements branch may yield some conflicts and I don’t want to be too greedy with my teammates review time.

I take a quick peek at GitHuband notice I got some feedback on the perf-improvements branch. I’m lucky to work with so many amazing programmers and the feedback is spot on, so I make the change. The change conflicts with my refactor commit, so I’m going to have to get a little tricky. git checkout HEAD~ algo.go puts the file I need to change into the state of the pull request. I make the change, commit it, and git share perf-improvements HEAD to add it to the pull request.

At this point my refactor will seem to have disappeared because I overwrite it with that checkout, but thankfully I can git rebase --interactive to rewrite the history on master to squash the new perf-improvement commit into the first one and move the refactor after them. Then I clean up the refactor commit a bit based on the pull request feedback from perf-improvements.

That last change to perf-improvements got it approval so I hit Squash and Merge on GitHub and git pull --rebase on my computer. If I hit any conflicts in the rebase I can either edit them and git rebase --continue or git rebase --skip if I want to just throw away the commit. I do that pretty frequently after I squash on GitHub.

Now I can share the refactor commit and put it up for review. The cycle continues with me putting a PR up and continuing on, and always pushing to get my PRs approved so I can send the next one up.

Is It Really Better?

The process above is certainly different from the GitHub flow, and it definitely forces you to rewrite git history regularly, but I think it’s a lot better than the GitHub flow for a few reasons:

Commits Communicate Clearly

In the GitHub flow commits tend to be a catchall for whatever you need to do to build the feature you’re building. With this process I strive to make commits clear, even to the point of amending them to ensure they’re focused on a single change.

I Keep Moving

This workflow ensures that I keep moving forward without having to look for a total change in topic to avoid conflicts. Back in my branching days I was constantly worried that moving to a new task would mean more branches that I would have to merge against my current one. Working only on master ends up being a simpler, more focused mental model that keeps me from maintaining local branches and trying to keep them all up to date when they’re interdependent. That ends up meaning more progress.

Review Stays Focused

When I share a commit for review it tends to stay very focused. I usually share reviews that are smaller than 5 files and that are trivial to read and review. They’re focused on just one type of change, and tell a story. That helps my reviewers by reducing their mental burden for that particular review and by reducing how much time they have to spend reading the changes.

And Finally

Moving to working only working on master and stacking my commits has been a major change in how much code I’ve been able to ship the past couple of months. It has made it easier to review my code and I’ve also noticed that my peers have given me approval more quickly. If it’s something you’re interested in, go ahead and install commondream/tbg and give it a try.

The history of the computer is something I don’t hear a lot about in my day to day work, and recently I had an urge to learn more about these amazing gadgets that I use for hours on end every day.

The Computer from Pascal to von Neumann came up almost immediately as a book I had to read. It describes the history of the early mechanical computers of the 1600s and works its way forward to the early 1960s. The author, Dr. Herman Goldstine, is especially capable of telling this tale since he was personally involved in designing ENIAC, the first stored program computer.

The Computer is fairly technical in places, so I’m not sure if I would recommend it to anyone not at all technically inclined, but for those of us who work with computers every day Goldstine does a commendable job of digging into the details of early computing history.

I usually find that the more I can keep my development environment aligned with production, the easier it is to work. I’m usually spending the majority of my time in my dev environment, so it’s always better to line the tooling up so that the techniques I can use for troubleshooting in development are the same ones I can use in production.

This post will walk through configuring a development logging infrastructure for a project on Docker Compose using Fluentd, Elasticsearch, and Grafana. The finished product will be a web interface for searching your development environment using technologies that you can easy run in production as well.

The Setup

This project will be using Docker Compose. The easiest way to install it is with Docker Desktop. Go ahead and create a directory for your source code as well.

The App

First up, the test app. Make a subdirectory in your project directory named randolog and toss this main.go file into it:

package main

import(
	"log"
	"math/rand"
	"time"
)

func main() {
	for {
		log.Printf("Some random log output %d\n", rand.Intn(1000))
		
		time.Sleep(500 * time.Millisecond)
	}
}

The program is pretty simple. It loops infinitely, writing out some random log data. It’s not ultimately that important what the program here does, so long as it has some log output for us to work with.

Docker Compose is configured with a docker-compose.ymlfile. It’s best to build that up piece by piece. To start, here’s the configuration for running the randolog program:

version: "3"

services:
  randolog:
    image: golang
    command: go run /usr/src/randolog/main.go
    volumes:
      - ./randolog/:/usr/src/randolog/

This configuration sets up a new service named randologusing go run to execute main.go. It is also mounting the randologsource code to /usr/src/randolog so that the source code is available in the container.

With that configuration it should be possible to run randologwith docker-compose run --rm randolog. Once it outputs some log messages, press Ctrl-c to interrupt it. The output should look something like this:

Configure Fluentd

Now it’s time to add Fluentd to the mix. Fluentd is a tool for routing log messages. It’s very flexible, but initially the configuration will only output log messages to stdout.

A custom will have to be built Fluentd image because the default Fluentd image doesn’t include the Elasticsearch plugin, which will be needed later in this project.

Add a new folder to the project named fluentd and add a folder named plugins under that folder. The plugins folder will stay empty, but due to a quirk with the Fluentd onbuild Docker image it has to be there.

Add a Dockerfile to the fluentd folder with this content:

FROM fluent/fluentd:onbuild

# below RUN includes plugin as examples elasticsearch is not required
# you may customize including plugins as you wish

RUN apk add --update --virtual .build-deps \
        sudo build-base ruby-dev \
 && sudo gem install \
        fluent-plugin-elasticsearch \
 && sudo gem sources --clear-all \
 && apk del .build-deps \
 && rm -rf /var/cache/apk/* \
           /home/fluent/.gem/ruby/2.4.0/cache/*.gem

This is pretty much a copy and paste from the fluentd image onbuild instructions on Docker Hub. This Dockerfile sets up an image containing Fluentd, the Elasticsearch plugin for Fluentd, and a custom fluent.conf file.

Before building the image create a fluent.confin the fluentd folder as well:

<source>
  @type  forward
  port  24224
  bind 0.0.0.0
</source>

<match **>
  @type stdout
</match>

This fluent.conf has two sections. The first, the <source> block, tells Fluentd to listen for the Fluentd forward protocol on port 24224. The second, the <match>section, tells it to output anything it recieves to stdout.

Configure Fluentd in Docker Compose

To run Fluentd the Docker Compose configuration has to be updated. Update docker-compose.yml to look like this:

version: "3"

services:
  randolog:
    image: golang
    command: go run /usr/src/randolog/main.go
    volumes:
      - ./randolog/:/usr/src/randolog/
    logging:
      driver: fluentd
      options:
        fluentd-address: "localhost:24224"
        tag: "docker.{{.ID}}"
      
  fluentd:
    build:
      context: ./fluentd/
    ports:
      - "24224:24224"
      - "24224:24224/udp"

This update includes two main changes. A new fluentd service definition allows Fluentd to be run with Docker Compose. Second, a new logging configuration for the randolog service tells Docker to forward logs to the new Fluentd service.

The fluentd service definition defines how to build the Fluentd image with Docker and also specifies that port 24224 should be available for tcp and udp. Using theportsdirective rather thanexposeis important because Docker log drivers don’t have access to the network running within Docker Compose, so it will connect to localhost rather than a Docker internal address.

The logging directive for randologtells it to use the fluentd log driver for Docker, which is built into Docker, and tells it to forward logs to localhost:24224. It also specifies a tag naming scheme.

It’s time to test that everything is working. Run docker-compose build fluentd to build the new Fluentd image. There should be a decent amount of output but no errors. Once the image build completes, run docker-compose up fluentdto start Fluentd. The output should look something like this:

Keep Fluentd running, and in another terminal run docker run --rm randolog to ensure that its log output is now directed to Fluentd. It should look just like it did before, but you should also see some log messages in the Fluentd terminal:

Connecting Elasticsearch To Fluentd

Now it’s time to set up Elasticsearch and tell Fluentd to forward logs to it. The Elasticsearch image is ready out of the box, so no custom image is required. Updatedocker-compose.ymlagain:

version: "3"

services:
  randolog:
    image: golang
    command: go run /usr/src/randolog/main.go
    volumes:
      - ./randolog/:/usr/src/randolog/
    logging:
      driver: fluentd
      options:
        fluentd-address: "localhost:24224"
        tag: "docker.{{.ID}}"
      
  fluentd:
    build:
      context: ./fluentd/
    ports:
      - "24224:24224"
      - "24224:24224/udp"

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.3.2
    expose:
      - 9200
      - 9300
    environment:
      - discovery.type=single-node

The only change here is the new elasticsearch service. It exposes ports 9200 and ports 9300 and configures Elasticsearch to run without a cluster.

The fluent.conf file needs to be updated as well:

<source>
  @type  forward
  port  24224
  bind 0.0.0.0
</source>

<match **>
  @type elasticsearch
  host elasticsearch
  port 9200
  logstash_format true

  <buffer>
    flush_interval 5s
  </buffer>
</match>

This update tells Fluentd to send all log messages to Elasticsearch. Any time fluent.conf is updated the image will have to be rebuilt, so run docker-compose build fluentd to rebuild it.

Start Fluentd and Elasticsearch now with docker-compose up fluentd elasticsearch,and then run docker-compose run --rm randologagain in another terminal. There should be log messages showing Fluentd connecting to Elasticsearch and Elasticsearch creating an index based on the log messages received:

Set up Grafana

Now that data is flowing into Elasticsearch it’s time to explore that data with Grafana. Just like Elasticsearch Grafana comes ready to go out of the box, so just updatedocker-compose.yml:

version: "3"

services:
  randolog:
    image: golang
    command: go run /usr/src/randolog/main.go
    volumes:
      - ./randolog/:/usr/src/randolog/
    logging:
      driver: fluentd
      options:
        fluentd-address: "localhost:24224"
        tag: "docker.{{.ID}}"
      
  fluentd:
    build:
      context: ./fluentd/
    ports:
      - "24224:24224"
      - "24224:24224/udp"

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.3.2
    expose:
      - 9200
      - 9300
    environment:
      - discovery.type=single-node
  grafana:
    image: grafana/grafana
    ports:
      - 3000:3000
    volumes:
      - ./grafana:/var/lib/grafana
    depends_on:
      - elasticsearch

The new grafana service runs Grafana and opens up port 3000 for browser access. It mounts a folder named grafanato save the state of Grafana, so go create that folder now. It also notes that Grafana depends on Elasticsearch.

Start it all with docker-compose up fluentd elasticsearch grafana. Now navigate with a web browser to http://localhost:3000. A login form will be displayed:

The initial username is admin and the initial password is also admin. Grafana will require the password to be updated on initial login.

Connect Grafana To Elasticsearch

After authenticating, hover over the gear in the left sidebar and choose Data Sources.

1. Click on the Add Data Source button to be taken to the new data source form.
2. In the name, enter Logs.
3. Choose Elasticsearch in the Type drop down.
4. Enter http://elasticsearch:9200 for the URL.
5. In Index Name enter [logstash-]YYYY.MM.DD and choose Daily in the Pattern field.

A success message like the one in the image below should display once you click Save and Test.

View The Log Data in Grafana

Now that a data source is configured, it’s time to build a log search dashboard.

1. In the left sidebar hover over the plus icon and choose Dashboard.
2. Choose Table as the panel type and a table will appear.
3. Drag the bottom right corner of the table to fill the window.

To edit the contents of the table, hover over the title bar for the table and choose Edit.

1. Click on the General tab and give your table the Title Logs.
2. Click on the Metrics tab and choose Logs in the Data Source drop down.
3. For the Metric field below click on Countand change it to Raw Document.
4. Click on the Options tab and change the Table Transform to JSON Data.
5. Click the + icon next to Columns and choose @timestamp.
6. Click the + icon again and choose log.
7. Close the edit panel.

The log data from randolog should appear in the table.

Filter the Log Data in Grafana

The log data is visible, but it’s not filterable. Filtering the data requires a variable to be configured.

1. From the dashboard, click on the gear icon in the top right corner to open the Dashboard settings.
2. On the left side, click on Variables and click the Add Variable button.
3. Under Name, enter filter.
4. For Label, enter Filter.
5. Under Type, choose Ad hoc filters.
6. Under Data Source choose Logs.
7. Click the Add button.
8. Click the back arrow in the top right corner to return to the Dashboard.

Ad-hoc filters apply to the entire data set being loaded in the dashboard, so no further configuration is required. To filter the data you can either enter a filter manually at the top of the dashboard, or you can hover over a value in the table and click on the icon for Filter for value or Filter out value.

When filtering data it’s important to remember that Elasticsearch is a full-text search index so searches will be by keyword, not with exact matches on phrases.

In Conclusion

Using Fluentd, Elasticsearch, and Grafana in development makes it easier to filter and review logs using a stack that can easily be implemented in production as well.

Each of these components is a very flexible and powerful tool. For example, adding the container_name field to the log table metrics list in Grafana would make it much simpler to review logs for multiple containers in a single Docker Compose configuration. Especially in architectures built on microservices this can be very helpful for filtering logs to the specific service being worked on.

The thing I miss most about Treehouse is the people. I worked with a phenomenal team and made friends that I still talk to with regularity. I worked for amazing students who still contact me from time to time — and who were the true reason that Treehouse excelled like it did.

Originally published at commondream.net on April 30, 2016.

One thing I’ve missed from Rails development, though, is automatic reloading, especially when doing web development. I found a few different solutions for Go, like gin, but many of them took over the compilation process any time a file is saved, and that didn’t feel quite right for me. After a little bit of thinking I decided I could solve the problem pretty simply, and created Reloader.

Reloader is the simplest possible solution to the problem that I could find. Pretend you’ve written an app that generates a binary named my_web_server. To run it in reloader, you simply append reloader to the beginning of your command line:

reloader ./my_web_server

Reloader will monitor the executable file for program you’re running and any time it changes due to recompile, Reloader will restart it with the command line you gave it.

I’ve been using Reloader for several months now, and haven’t needed to change it in a while, so I think it’s ready for others to try. You can learn more, including how to install Reloader, in the README.

Originally published at commondream.net on April 27, 2016.

Over time I’ve picked up some informal questions I ask while interviewing. Initially these were questions that helped me understand the founder’s vision for the company — questions like:

• What does success look like for your company?

Believe it or not, most early stage companies hire without knowing what new employees will be doing. It’s always good to figure out those expectations (or lack of them), so I started asking:

• What will I do each day in this position?
• How will you know that I’m doing a great job?

After I wasn’t paid my last couple of paychecks because one company ran out of money, I added questions about company finances and financial transparency to the list:

• How much money is in the bank?
• How much cash are you burning each month?
• How do you communicate the financial situation of the company to the team?

All of these questions have helped me understand how young companies I’m thinking of joining operate and how they see me fitting into what they do. After thinking back on what has happened in each of the positions I’ve worked in, though, I’m adding another to my list:

• How do you hold yourself and the executive team accountable to make good decisions?

Many young companies lack structures to keep founders and the executive team accountable for making good decisions. Here’s a list that of problems with executive accountability that I’ve seen fairly frequently, but it’s by no means exhaustive.

Total Control

Companies that haven’t raised capital (or that don’t intend to raise capital) typically end up in a structure where the founder or founders have enough ownership of the company to have total control. That’s very often exactly why founders start a company — the freedom to make whatever decisions they want and to learn as they iterate. But at the end of the day, the whole team is building the company and the whole team deserves the ability to give feedback and raise red flags when they see a problem. Everyone’s jobs are ultimately on the line.

Founders operating with a strategy of total control often talk about responsibility being on their shoulders or about how the company is theirs and you just have to trust them. Don’t be surprised if their voice softens a bit when they tell you this.

It’s not wrong for a founder to have total or majority ownership of a company, but founders must accept that as soon as they hire employees they’re giving up total control of the business.

The Ineffective Board

Many companies have almost useless boards. The board meets irregularly and when they do meet there’s a lack of transparency. The founder sees the board as an adversary to be defeated, rather than a group of trusted influencers for the company. You’ll often hear executives with ineffective boards mention that board meetings are a waste of time.

If you have shares as an employee of a young company, the board should be supremely interesting to you as an independent group protecting your interests in the company against bad decisions by the executive team. You want to hear about a board that really takes its time and works hard to ensure the executive team is doing its best work.

The Silencing Effect of Equity

Equity in a company can have a silencing effect on the team. Here’s how that usually works:

1. The company issues options or restricted stock with a vesting period and other purchase terms, typically with a contingency that if an employee leaves the company or is fired they have to exercise or void their equity.
2. Some time after equity is issued the executive team makes a decision the team disagrees with.
3. The team pushes back a bit.
4. The executive team says the decision is final. They often include a warning about how they’re totally in charge, how this is the right decision, or any of the other lines of thinking mentioned in the section about total control above.
5. The team decides that they’d better not rock the boat because it could mean losing their job and all that equity that they’ve worked hard for but that still isn’t fully vested (or that they can’t afford to exercise in the case of options).

I’m not totally sure how to solve this problem, but I think rewarding stock as a reward for great performance after the fact could be one way to help handle the issue.

Not Really Listening

Some executives have no issues with transparency, but still don’t actually listen when feedback is given. It’s pretty easy to imagine what happens next — the team stops giving feedback and ultimately knows that the transparency is worthless, except maybe as a warning sign of when to bail out. That lack of response to feedback ultimately ends up with the same outcome as if the feedback had never been given.

Back to the Question

It’s important that founders and executives know that what they’re doing is visible and that they’ll receive clear feedback on what they’re up to from other rationally thinking humans, whether it’s the team or an outside advisor or board. So back to the question:

• How do you hold yourself and the executive team accountable to make good decisions?

There’s no right answer, but there are many clearly wrong answers. Answers like:

• “We just make great decisions.”
• “We understand that ultimately success is on their shoulders.”
• “Failure’s the ultimate accountability.”

are pretty clear signals that you should be on guard. You’re dealing with someone who hasn’t set up much accountability for themself.

If you hear answers like:

• “We meet with the board of directors monthly for a few hours and discuss all major upcoming decisions and the results of past decisions.”
• “We communicate openly with the team and actively seek their feedback about decisions.”

you’ve probably found a company that’s on the right track.

So I buy a new computer, and it has Windows 10 on it. It’s way better than Windows 8, but I had to take all sorts of junk off of it, and it still had the Windows App Store. What am I going to do with an app store? I use the web and I use Excel. Excel’s a program – I have no use for apps.

A good friend of mine made the statement above while we were catching up over the phone the other night.

This perceived difference between apps and programs was really interesting to me, and I dug in a bit more to try to get a feel for why he thought they were different. For him it seemed to be about value — apps are cheap or free and functionally trivial, while programs are more expensive and are for serious use.

This conversation was a nice reminder for me that my perspective as a person who builds software almost every day is often fairly different from the people I’m building software for.

Today, though, I stumbled across pstree, which displays the process tree much more cleanly. It’s installed by default on Ubuntu, so you can run pstree -p to show a tree of all processes, with pids, like this:

You can learn more on the pstree man page.

• Yet again, it’s a Rails app. We tested out a lot of language and framework setups before we landed on Rails. I’ll hit my 10 year anniversary of working with Ruby and Rails next year, but it’s still my favorite framework/language combo.
• We’re doing dev in Vagrant boxes rather than directly on our systems. It’s been cool, but hasn’t always been the easiest setup.
• Both our production servers and our Vagrant boxes are built out with Ansible. It’s been a pretty cool tool, and has had a lot less mental overhead than Chef.
• Gulp is replacing the Asset Pipeline for us. I think it’s a good decision, but it hasn’t always been completely easy. We’re processing JS with Babel, though, and ES6 has been great.
• We’re focusing more on feature specs than on unit testing controllers. I’ve been a huge fan of that.
• Although our app is primarily a rails app, it already has a couple of additional projects attached to it, and we’ve built everything out in a single monorepo. I’ve really liked that format.
• We’ve got a pretty small team of 5, but we made a concious effort to start hiring a mix of more experienced and less experienced developers from the beginning. I think it’s really payed off in diversity of ideas and in forcing the team to understand the tradeoffs of different decisions.

As far as the company goes, I’ve been really impressed with the team at The Iron Yard and their student focused approach. Each day carries tons of discussions of how we do what’s best for students, and that’s been a lot of fun.

no one will.

Indeed, the most productive employees don’t necessarily work the longest hours. Instead, they take the smartest approach to managing their energy to solve tasks in efficient and creative ways. — Derek Thompson, A Formula for Perfect Productivity: Work for 52 Minutes, Break for 17, The Atlantic

At Treehouse, we’ve got this weird thing called the 4-day work week. It’s not a gimmick, it’s not the 4-hour work week, and there’s not some 4 days of working 10 hours scheme going on. We really work 4 8-hour days each week.

The 4-day work week ultimately boils down to the beauty of constraints. Ryan, our founder, and his wife, Gill, had the hypothesis that smart, motivated people given only 4 days per week would recognize how precious those 4 days are and take full advantage of them. Work smarter, rather than harder. You know the drill.

Overall, I’d say their hypothesis has been proven in resounding fashion. Treehouse has grown very quickly. We’ve built a product, team, and company that we’re all proud of. We’ve had so much fun doing it. Also, we’ve had an extra day with our families and friends while we’ve accomplished all this.

I haven’t been very good at working 4 days per week, though. Especially not when it comes to mental work, but I’ve also worked most Fridays in the almost 4 years that I’ve worked on Treehouse now. That’s probably not a good thing.

All those days, and honestly I can’t tell a single story about the great work I did on a Friday that really made a difference. That’s probably not a good thing.

I have a really hard time turning things off and spending time on my family and myself. That’s probably not a good thing.

There’s an insidious phrase rattling around in my head that drives me to work on Fridays, and it may well drive you to work harder, rather than smarter, too:

If I don’t do this, no one will.

This phrase can drive you insane. It can cause you to question everything. This phrase breeds distrust in your team. “Why aren’t they doing this?” My emotional response is that I’m all alone. The real answer? There are more important things to be done than my idea from 30 seconds ago.

The phrase breeds a feeling of self-importance. “I’m the only one willing do this.”

The phrase takes away your ability to focus and prioritize. More and more work doesn’t mean better and better work. “Focusing is about saying no.”

I’m going to try and be a little better about these things. I don’t want to be the kind of person who ultimately mistrusts my team, feels self-important, and misplaces priorities. I want to build really great stuff and I want to be deliberate about how I build it. Most of all, I want to be the kind of person that people remember working with for the right reasons.

So today (a Friday, no less) I’m paying my bills, writing a silly essay, and then reading while I wait on my kids to come home from school. I’m hoping I’ll try talking things out with the team the next time my brain says “If I don’t do this, no one will.”