They All Ship

(Note: This post is the first of many in which I reveal or discuss the traits and techniques of people throughout history who have built great things.)

Ira Glass:
The most important thing you can do is do a lot of work. Do a huge volume of work. Put yourself on a deadline so that every week or every month you know you’re going to finish one story. It is only by going through a volume of work that you’re going to catch up and close that gap. And the work you’re making will be as good as your ambitions.

Venkatesh Rao:
“Releasing. As in the agile software dictum of release early and often. In blogging, frequency isn’t about bug-fixing or collaboration. It isn’t even about market testing … It is purely about rational gambling in the dollar-cost averaging sense. It is the investing advice ‘don’t try to time the market’ applied to your personal work.

Taylor Pearson:
You need to put yourself on a deadline and ship. ‘Ship’, a term from Steve Jobs’ line ‘real artists ship’ and popularized by Seth Godin, is an essential difference between work and The Work. … The Work may be the best way to achieve the goals that many people seek through work.

Dan Norris:
Understand that you have two choices: to create something or consume something. The only thing I know about successful people is that they create things. Create so much they can’t ignore you.

All form the same idea: shipping, releasing, publishing, producing, etc. That is, make something, then make it accessible to others. Writing in your journal does not count as shipping — posting on a blog does. Playing guitar does not count as shipping — uploading a song does. Doing code puzzles does not count as shipping — contributing to open source does.

Every majorly successful person I can think of (or at least those that have attained household name status) are shippers. They release a lot. They have an air of prolific mastery. It’s magic. How do they get so much done?

One example: Robert Moses.[1] He’s perhaps the most prolific public official to have ever lived. He was New York City’s Parks Commissioner in the first half of the 20th century. He simultaneously held 12 state and local titles. He built 2.6 million acres of parks, 658 playgrounds, 416 miles of parkways, and 13 bridges. He worked tirelessly and ceaselessly. He had grand, clear visions. And he didn’t compromise. In the styling of biographer Robert Caro, he “Got Things Done;” he shipped.

Robert Moses is the rule, and not the exception. The biography section is filled with men and women like him. What explains this commonality? Consider a few observations:

  1. They’ve had such an impact because they’re excellent, and they’re excellent because they’ve consistently shipped. Ira Glass, speaking above, said that every maker has a gap between their taste and the quality of their output. Only by producing a lot, can you close that gap.
  2. Part of the love (arguably narcissism) they had for their craft was seeing it affect the real world. They had a sincere extraverted aim to their work: to publish it, to bend reality, to put a dent in the universe. Jerry Seinfeld didn’t just love comedy, he loved to make others laugh. And that love drove him to keep producing and getting better.
  3. A quickly expanding body of work attracts attention, which is a major aspect of success. People remember your one hit, not your entire back-catalog of flops. More work gives you more chances to strike a chord, as Rao said above.

Shipping is something that everyone can do. As a creator, your work is obvious — create and publish. But for knowledge workers, your shippable work is not so easy to identify. If you’re a leader or a manager, how do you ship?

Again, look at the example of Robert Moses above. He didn’t lay bricks or thread suspension cables across bridges himself. Instead, he was the coordinator behind the projects. As they say: he didn’t make it, but he did make it happen. By deftly delegating to and wielding an organization that was able to produce so many public works, he got the credit and became the man who “got it done.”

In knowledge work, it’s similarly important that the project you are tasked with gets done. Maybe that means you execute on it yourself, or maybe that means you enable others to. The bottom line is to build a reputation such that people feel confident entrusting you with responsibility. And you do that by shipping.

Shipping quality work over and over has been shown throughout history as a sure way to get good, to get noticed, and to get rewarded. So do the work and ship.

[1] “The Power Broker: Robert Moses and the Fall of New York” is a majorly influential book on me that you will surely see more references to.

Should you learn to code? Probably not.

Ever heard this: “everyone should learn to code?” Or that “the jobs of the future are all going to be coding jobs,” followed by recommendations to retrain hoards of middle-age and coal miners?

Mike Bloomberg signaled the peak of this idea in 2012:

I wonder how much those coding skills helped him in his presidential bid.

The idea is still strong today, but I don’t know why. Is there some dev bootcamp cartel out there pushing this narrative? It seems like common sense, but I don’t at all agree with it. Here’s why.

Coding well is really hard. It’s like learning how to do an abstract branch of mathematics in Portuguese. You have to use thought processes you likely haven’t used before. And you need to be incredibly detailed and particular because a machine will do exactly what you tell it to. Until it doesn’t, which leads me to…

Completing projects takes insane levels of grit. There’s a saying that the first 90% of software development is writing code, and the last 90% is debugging. Debugging means chasing an error around dozens of code files while banging your head against a wall until it goes away, only to find, like whack-a-mole, that another error popped up somewhere else. You know those people that can play a single level in a video game over and over for hours because they just need to beat it… you need that level of frustration tolerance and commitment to discover that a single Chinese character in a text file you didn’t write is the reason your whole program broke.

And then understand that you don’t just write code for yourself, but also for your future self and for others. A key aspect of good code is how readable and clear its intention is.

Code Quality

But the most important point is that you’ll likely never use the skill. I do a lot of coding for a living, and I barely program outside of work. Sure I’ve done some projects on the side, but the code I’ve written for myself and actually use is minuscule compared to my entire catalog of work.

So what you face is a very difficult skill that has likely very little to no payoff unless it’s for your job or you like to tinker with data and computer systems for fun.

When you should learn to code

However, if you like solving difficult and nebulous logic problems, then coding is probably something you’ll enjoy. And if you really enjoy it, then it might be worth making a career out of it. Because you kind of need to enjoy it to be good. But you don’t necessarily need to be a Putnam contender to get something out of learning to code. There are good reasons to learn code, even if you don’t want to make it a career.

  1. You have personal work tasks you’d like to automate. Maybe it’s pulling files from a server, or writing macros in Excel. You don’t need to learn a lot of coding to make these kinds of tasks much much easier. And having a motivation for why you’re learning (and a specific project to work on) helps tremendously. For example, I do all of my budgeting and tracking in a Google Sheet. At the end of every month I have a script that creates a new sheet, cleans it up, and resets values to begin tracking the new month. Don’t need to be a pro for that. (A free book recommendation: Automate the Boring Stuff with Python)
  2. You like math and puzzles. Did you like solving logic problems as a kid? I had stacks of logic problem books. Coding is the adult version of this where you create and solve your own logic problems at the same time. It genuinely can be fun. It’s a quick way to enter a flow state. So maybe it’s a fun little project or hobby. Which, incidentally, is one of the best ways to start before you decide to…
  3. Make a career change. This is the positioning that the bootcamps take. Yes software can can be a lucrative and fulfilling career. You get to create every day. But as mentioned above, it takes a certain type of person to really enjoy this enough to be good and make a career out of it.

Okay so you want to code. Here’s my recommendation.

First, figure out which of the three reasons above applies to you. Having a really good “why” to come back to will help keep you motivated and focused.

If you’re learning a specific task, like Excel Macros, watch a few YouTube tutorials and then just start hammering away at the task you want to complete. It’ll be hard, but that’s part of the learning process. You’ll find yourself on Stack Overflow frequently. And there’s likely a community of people willing to answer your question (nerds love answering questions and looking smart. Wait, I mean they love teaching).

If it’s for enjoyment, learn the basics of Python. Then head over to Codewars or Project Euler and just start solving problems. Again, it’ll be slow going at first as you learn the syntax, the libraries, control flow, etc. If you find something was challenging, read the corresponding chapter in a book like this:

If it’s for a career change, first figure out if you like it (again, a good indicator is if you easily get into a flow state). Then a bootcamp might be a good idea, but you can certainly do it on your own. But no matter what, doing a lot of work, inside a system of accountability, is the only way you’ll get good enough to get hired. When I hired engineers that came out of bootcamps, having command of the theory and having done a lot of creating were musts.

This is the advice I’d give to a friend who is thinking about coding. I took the traditional path of starting with high school computer science and majoring in it in college, so I didn’t have to retrain myself. So maybe this doesn’t work for you, but find out what does (harder than it sounds, I know). For any pursuit in general, focus on the process and the result will take care of itself. As Mihaly Csikszentmihalyi, the popularizer of the concept of a “flow state” said, “it is when we act freely, for the sake of the action itself rather than for ulterior motives, that we learn to become more than what we are.”

To summarize: Learning to code is likely a waste of time. But if it is right for you, make sure you know why. Then approach the task appropriately.

Questions? I’d love to answer them to appear smart. I mean teach.