On Distractions and Tools

I’m writing this blog post to relate the following:

I’m planning a reading tour through the American Revolution, probably starting with Ideological Origins of the American Revolution, by Bernard Bailyn. It stood out most to me after perusing multiple pages for good starting points.

Truthfully, I’m writing this blog post to relate why I’m planning a reading tour through the American Revolution. It was instigated by my sudden desire to get a grasp of the basics of the Revolution and the people and ideas around it. That came out of peeking into an IRC channel full of my American friends. Which happened because I opened my chat terminal session. Because I’d just logged on to my server.

I logged onto the server to change my status page from working.gif to dancing.gif. I was doing that because I had just visited my own blog and seen the status-page post on it. I visited to… write a brief post, about doctype vs DOCTYPE in html5 documents. I was writing that post to relate some amusing and interesting facts that came out of researching it. [1]

I found those facts after an instance of “DOCTYPE” in Bootstrap’s examples set me off reading about why people prefer the different casings and whether they matter at all.

That’s all because I sat down half an hour ago, thinking, “I should make a quick stab at building my list-webapp page, or at least think about it.” I’ve since been like a ping pong ball zooming back and forth between making and consuming, flung by inspiration and curiosity. Continue reading

Our Corporate Vision

We will do everything.

Everything that everyone does, they’ll do it through us. Email, music, notes, chat, storage, web browsing, we will do all of it.

We’ll combine all of the disparate services you and everyone else use, and all of the different data bits you have on all of your computers, and we’ll deliver it to everyone in a better interface than any of the other jokers out there can manage.

We’ll by default be sleeker and faster and easier to use and more powerful, but we’ll also expose a rich programmability to allow power users to have total control over their environment and information. They’ll be able to share and modify each other’s improvements and help everyone who uses us become better.

We’ll let you use whatever storage backends you want — we probably can’t compete with them on price — but we will encrypt everything we get as it comes into us and as it goes out and we’ll only store the encrypted data for backup purposes for customers and we won’t ever look at it, and we will utilize a law enforcement requests canary and whatever other means we can to protect our and our users’s privacy and rights.

We’ll make our service available on every platform in every way imaginable — iOS, Microsoft, Android, FirefoxOS, our own custom mobile OS forked from Firefox’s, webapps, desktop clients, web browser extensions and even our own web browser and operating system.

We won’t just think different. We won’t just not “be evil.”

We will be everything, to everyone, and not just organize the world’s information, but give it back to them neatly folded on demand and guarantee them that we never ever fucked with it.

When we have made ourselves indispensable, when we have paid back our investors 10x their input and guaranteed ourselves financial independence, we will set the whole thing free and operate it as an international non-profit organization devoted to the global betterment of computer technology and its availability.

We will become a fundamental utility, and we will make ourselves universally available for free, forever, as soon as it is possible to do.

Free as in libre, and free as in beer.

How to properly build what you want to build.

To build something you really want to build, and build it right, you need time and expertise. You may need money. You will likely need more of all of them than you’ve currently got, unless you are Bill Gates and it’s the mid-1980s.

Time is non-replenishable. You can’t get more, so use what you’ve got well. Expertise is readily available from other people, who’ve spent all of their time becoming experts, but they will only give you their time in exchange for money. True experts often need a lot of money, maybe because they spent a lot of time. Money can come by a variety of means:

Let’s discount finding it in a ditch, and you probably already know that you haven’t inherited it. You can borrow a very limited amount of it with sufficient collateral, but then you must repay a larger amount. You could have it invested in you by investors, but they also want a larger pile to come back, and building something really properly isn’t a surefire way to do that. Plus, they don’t know you or what you’re capable of, so they’d probably never give you the huge sum of money you need. You’ll probably need to get paid, by a large number of people. Preferably on a recurring basis. So you’ll have to have something lots of people want.

Discounting finding that in a ditch (ditches are not the treasure trove modern media may lead one to believe) you’re going to have to make it yourself. Again, you need time, money, and expertise, but less of each than before. You can free up your work-time by having money. A loan is still an option, but betting collateral on your business is a recipe for disaster. So maybe try for a smaller investment–you’ll have less to prove than for the larger sum, so you may just need a solid track record, a good reputation, and to pound the pavement. (Plot hole: let’s ignore nepotism, groupthink, and social status.) You could try to skimp on time by continuing to work, which would free you from the investment.

Expertise in this case is ‘just’ knowing what people want, and how to build it well enough that it doesn’t anger them–usually easier than really building something right. This also comes back to a track record. A track record is just a history. It’s building things, time and time again.

How do you build things? Decide on something that you do not already have, then dream up a possible way to make it, and set to work. You don’t have to know exactly how when you set out. You probably won’t need to learn how either. You will quickly figure out what things you really need to learn by trying to do what you want, and failing.

So try. Go start now.

Try something out, learn what you need to learn by making mistakes, and build what you want to build by actually doing it. Don’t do a tutorial, don’t look up background research, don’t read an introduction to the language. Don’t open Hacker News. Don’t reinvent things–use the tools, frameworks, and freebies that flood the internet. Get out there and script-kiddie-lego-monkey-duct-tape-copycat it until you absolutely can’t go further. Then fix just enough of the hole in your knowledge so that you can keep going, and get right back to it. There are no barriers to doing something now.

And don’t worry, I promise you you’re learning things, no matter how janky your stuff is. Building it properly will come later. Building anything comes now.

What’s next after starting? Well, that’s another hard part: continuing. You have to keep building your thing. Then you have to finish it, which is also hard. Then you have to move on and start again, and do the whole thing over, preferably something pretty different. Then do it over again, and over, and over, for a long time. None of the things you make will be the track record on its own, and none of them will impress investors, or customers, or even necessarily you. Until one day, something you made does impress somebody. It won’t happen until it has, but as you work, the chances go up and up.

Why is continuing so hard?

Because it means not going out tonight. It means not sleeping in tomorrow, and not going to sleep now even though you’re tired. Not seeing your family right now, or catching up with your friends this time. Not working on your other hobby. Not eating healthy, or keeping up on exercise. It means not reading, not writing, nor volunteering, not staying at work late because you zoned out a bit that day and just need to finish one more little thing. It means not getting home and turning on Netflix. It means seriously choosing not to lose track of time scrolling through social media feeds.

It hopefully doesn’t mean all of that, or even most of it–if it means most of it for you, it’s getting unhealthy. But it does mean some of that, sometimes, and which bits is different for all of us. Honing the skill of continuing is going to be more of that bad stuff than you want it to be.

So, continuing is hard. It’s a trade where you decide what you want more, what you think is worth more to you: building things, or other stuff. For most of us, other stuff ought to be more important. You can and should try to find a balance, but be honest at the outset: if you want to do something difficult, you will have to make real sacrifices, and do real work.

It’s also hard because continuing means facing yesterday’s choices. It means a lot of boring fixing and tweaking and hitting your head against a wall. It means doing the things you haven’t already done before, and the things you didn’t do first out of sheer excitement. It sometimes means closing doors on ideas, and admitting you made mistakes. It is by definition hard work. Much harder than starting.

Why is finishing hard?

It’s everything that was hard about continuing, taken to the extreme. The last mile is nearly totally populated by boring minutia. It’s also got those really hard, annoying problems you managed to avoid solving. It’s all polish and review and stupid bugs you thought you fixed, and it takes an impossibly long time. It’s full of people not liking your baby, complaining about things outside of your control, and using your stuff wrong.

So, finishing means being devoted, empathetic, and humble. It’s done by understanding the flaws in your own work and splitting that work away from your ego, and just gritting your teeth and doing every little thing that needs to be done. It will never really be done–nothing ever really is, but at some point you will find it receives more use than abuse. More compliments than complaints. While we’re here, be careful about glowing comments from loved ones. You pretty much have to entirely discount their happy opinions on this. Only angry internet strangers’ approval matters, because theirs is the hardest to win. They are the people you want to pay you some day.

Some day, after you start, and continue, and finish, and build a track record, and (maybe) take money, and build something people want. Then, you can hire people who are really experts, and build what you want to build, and build it right.

So, why is starting hard?

It isn’t. People only think it is.

People see all the stuff above, and get caught up worrying about where or whether they’ll fail. Sometimes they wisely discover that there are other paths, or that they care more about building things properly than choosing what to build (maybe they’ll become an expert). Maybe they simply value the rest of life more. Some people spend years or decades planning to start, and just never really do it, or they never start what they think they wanted to.

But it is actually easy to start. You just start.

Write once, copy once, refactor once.

This post is about effectively using your time. It is not a defence of taking on huge technical debt to make your life easier for a single day, and you are hopefully smart enough to avoid doing that. It’s just a simple approach to growing a system you’re working on while avoiding duplication of effort and over-engineering.

Write once.

The first time you have to do it, just get it done. You’ll be in the best position to improve your solution once it actually exists, by knowing real things about how well it solves your problem. Plus, at that point, it’s already solving your problem.

You may be tempted to figure out the best solution before writing anything, which in my experience is a huge waste of time. If you haven’t written it yet, figuring out which bells and whistles to add is time-consuming and error-prone.

Copy once.

You got it done, a week passes, and a new problem comes up that feels almost the same. Assuming you can’t just use the thing you wrote before, you can:

  1. Refactor your code to make the original useable in both spots.
  2. Copy your code to the new spot.

Most people want to refactor now, but I think you should copy. Why?

It is very hard to determine patterns from just two examples.

With two instances, statements about the group as a whole are wild guesses. A simple illustration — consider these two numbers: 1, 2, …

The next number might be 4, 3, 1, 57, or anything else. No clear pattern shows up, because two data points only have one relationship, and patterns are formed from the relationships between things. Try three numbers: 1, 2, 3, …

4 is next, and I’m sure you saw it coming. This example is admittedly a little weak, but it clearly illustrates that patterns can leap out at 3 things, while being unclear at 2. With three things, you can have up to three relationships, and similarities between multiple relationships are way easier to be think about than similarities between … one.

Refactoring after two instances

Let’s say you chose to refactor. You put the shared code somewhere ideal for the two cases you know, and rewrite the tests.

Two weeks later, the problem shows up elsewhere. Is the code useable right away in this new spot? If you’re like me, you gave your abstraction the smallest scope necessary, and you’ll probably have to move it again. You parameterized the minimum amount required, and you may have to add new controls. That was all wasted time and effort.

So just copy it!

Almost no effort needed. You’ll probably have to refactor in two weeks, but you didn’t waste the time today.

Objections to copying things:

“I might forget to update a copy later!”

“Copying and pasting leads to typos!”

These are both valid points. In the first case, making synchronized changes might lead you to refactor (after all, you’ve already written once and copied once), and in the second case, the risks aren’t as big they seem. The second case has a nastier form:

“That’s not DRY!”

Not repeating yourself is a well known rule, and endless repetition is obviously bad, but I caution readers to ensure that they aren’t following DRY blindly. You should consider things like the following:

  • will your code be easier to read with a copy, or with a new abstraction?
  • will the abstraction that makes sense today last beyond tomorrow?
  • will a bad abstraction be harder to remove than repetition is?

As for copies and typos, most people are intelligent and careful enough to deal with a single copy well. The real horror stories occur when you make several copies (3+) of something and they’re all just a little bit different. Don’t make three or more copies: just copy once.

Refactor once.

Back to that choice from earlier: say you’d copied it instead of refactoring. Now it’s two weeks later and you hit a third instance of the problem.

As a quick aside, the “third instance” may just be a need to change your code in both copies. This is a sufficient condition to refactor. Two distant, identical pieces of code needing similar non-trivial changes is a great way to create a bug by messing up minor differences of context. After you’ve written once and copied once, the next step in this approach is always to refactor once.

With three instances, you have a good chance of finding patterns. A quick refactor here is going to yield even better code than a slow, thoughtful one would have with just two instances of the problem. Context rules.

Before we move on, what exactly does “having three instances of the problem” and “the next step is refactoring it” mean? There are two paths upon discovering you need the code a third time:

  1. Make a third copy just to see how it fits and that it works, then refactor.
  2. Jump straight to refactoring the first two, and just apply the solution.

The first choice takes longer, but is safer: your code never leaves a working state. This is a little bit like long-division. In complex situations, or when you’re less experienced, it’s best to write everything down. You’ll know which feels right when you’re in this position.

The Fourth Instance

What if two weeks after your refactor step, you hit the problem yet again, and for some reason you can’t just use your past work? Why not write once, refactor twice? Or write once, copy twice, refactor once?

In my experience, the fourth-instance-that-doesn’t-fit-the-pattern is surprisingly rare. Refactoring at the third instance is usually good enough for a long time, so doing it then minimizes the odds that you’ll have to refactor the same thing twice in a short period.

As for copying twice and refactoring at the fourth instance… this gets back into that “three copies or more” zone, where it gets hard to keep minor differences between your solutions straight. Feel free to try, but I bet you’ll find it to be a serious, bug-causing hassle.

Write once, copy once, refactor once.

  1. It’s faster.
  2. It’s only slightly more error prone, if at all.
  3. It will probably yield better code in the end.

So do what the title says.