mechanical_fish

We'd spend hours watching TV, often while simultaneously being really bored. I can hum the theme song to "Eight Is Enough"; nothing found on Facebook is more terrifying than that.

The amount you're trying to save with "option 4" can be estimated fairly accurately; it's about 0.09% per year. [2] Over forty years, this savings will compound and you'll make 3% more money, if you never screw up the rebalancing, and if you're at least as talented as a Vanguard analyst, and if you remain so even as you grow older.

But the US market has gained more than 5% per year on average, so you could make the same money by just investing for six extra months. Or, looking at it the other way: If it costs you six additional months to get started with option 4, you've just thrown away all your potential gains from option 4.

And option 4 has a much harder conversion funnel. You have to:

  1. surf to Amazon
  2. get the free Kindle version of William Bernstein's *If You Can* [3]
  3. read it
  4. Contemplate the inevitability of your own death.
  5. build a spreadsheet
  6. Make some strategic decisions
  7. open a Vanguard account before noon tomorrow
  8. Carry out at least four trades.
  9. Set up an automatic investment plan.
  10. Repeat steps 4 and 7 every year without fail for the rest of your career.

patio11's advice converts better:

  1. Open a Vanguard account before noon tomorrow.
  2. Visit this page:

  ... and pick the fund that matches your age.

  3. Buy some of that fund.
  4. Set up an automatic investment plan to buy more of that fund.

---

[1] I should know; I have followed this terrible advice for years. Writing this essay may be the best investment I've ever made.

[2] Vanguard's Target Retirement Fund for 2055 (VFFVX) has an expense ratio of 0.18% and would be managed for me.

Or I can follow Vanguard's strategy on my own. At the moment, Vanguard's VFFVX consists of:

  54%  VG Total Stock Market index (expense ratio 0.05%)
  36%  VG Total International Stock index (expenses 0.14%)
  7%   VG Total Bond Market II index (expenses 0.07%)
  3%   VG Total International Bond index (expenses 0.19%)

[3] Technically the book I read back in the day was Bernstein's Four Pillars of Investing, but I'm assuming that Bernstein has diligently refined his teaching over the years and I can safely recommend his latest.

I don't recommend the alternative of seeing some of your friends or relatives drink themselves to death, even as their own closest friends fail to see what's going on. But you don't always have a choice. Sometimes the anecdotes find you.

Anecdotes aren't data, but they are what human beings are designed to believe. If you have trouble envisioning evident facts that are backed by piles of data, perhaps you need to collect a wider range of anecdotes.

Don't get me wrong, I own and rather like Rumours, though I cannot spell it. It helps that, after spending a decade mostly not listening to classic-rock radio, I can hear the thing with fresher ears.

The pop single was a great product in its day. The recording industry invented pop singles and then spent fifty years perfecting the machine to market them.

To focus the marketing, singles were released a few at a time, and radio stations were encouraged [1] to play the same small playlists relentlessly, over and over, day and night. We all got used to the fact that there were only a few hundred songs on the radio and that they weren't merely free, but inescapable.

To further focus the marketing, the audience was relentlessly diced into genres, and high walls were built between the genres. Sorry, no hip-hop here, this is a rock station; Sorry, no zydeco here, this is a country station. We all got used to the fact that each of our local radio stations had a sound that never changed, and that you could name the songs that would be playing in a bar before you walked in. (Hint: Hotel California.)

For a while there, bands would release carefully-crafted albums that were designed to be listened to in a sitting, but the radio would never play whole albums except on very special occasions. Also, long songs would generally be abridged or avoided. We all got used to the fact that music came in randomly-shuffled three-minute chunks, which just happen to be really quick to download and easy to stuff onto USB sticks.

Then Mephistopheles appeared, holding the first compact disc, and the industry's doom was sealed as it realized that it could make an easy fortune by selling the baby boomers' music to them over again in a new format. And, indeed, that fortune was made. The industry's focus shifted to the past, and parked there. They made a lot of money selling copies of Rumours and Dark Side of the Moon to multiple generations of listeners, and they invested in branding juggernauts like Madonna and Michael Jackson that promised to sell albums for the next fifty years, and we all got used to the fact that one could pick up a copy of Rolling Stone and have difficulty figuring out which year it was from.

Plenty of people complained about this system at the time, but it did make money. Until Napster and Apple came along and said "Hey, your entire musical universe fits inside a small box like this, would you like one? It won't take more than a week to build a collection that is better than the radio." And then, whoops, the meteor hit the dinosaur right between the eyes.

---

[1] This kind of encouragement: https://en.wikipedia.org/wiki/Payola .

Your English looks flawless to me, by the way, so don't sell yourself short: you can learn to write like a pro, you may already be there, and describing what you have done and what you are going to do in written English prose is where the money is.

Are you actually a Wordpress themer? Learn just that much PHP and you can get all kinds of little gigs, doing work like customizing themes for people's Wordpress or Drupal sites. The advantage of learning a package, like a CMS, is that they lend themselves to little jobs, because most of their code is not customized and oftentimes the custom code is, shall we say, easy to improve. And if you are looking to fill time for a few months - and practice those vital pitching and customer-communication skills - little jobs might be nice.

Incidentally, at some point you might really want to practice whiteboard interviews, but if I were to do that I would specifically practice whiteboard interviews, not TopCoder or algorithms. Whiteboard interviews are a specific skill all their own. That skill is at least as much about being able to think out loud as it is about what you are actually thinking about. Knowing more algorithms might not help. I have found it more valuable to be able to implement bubble sort while telling jokes about bubble sort than to know what quicksort is.

"Hello, coworker! Did you enjoy the cake we both got to eat the other day in the company cafeteria?"

"By the way, I'd like to ask you a question, and don't worry: This isn't an interview or anything, so if you can't answer me right away, or if your answer lacks grace, it's not as if you'll lose your job."

"Anyway, coworker: I found this code, which you wrote while working for my company, under the direction of my company's management, and which solves a problem that my company actually has, and which builds upon my team's platforms, languages, and coding standards, and which might even link directly to my code, and which both of us have had a moment to read and think about and which is right in front of us on this monitor. How does this code work?"

"Also, can you help me debug this code I have here? It builds atop the code I showed you last week, and is written in the same language that we all use, and attempts to solve a problem you've seen before – which is not a coincidence, because you were the person who asked me to solve the problem."

These questions are incredibly relevant to our work, but interviews can't cover them. Candidates are not our coworkers and they share none of our context. Instead, interviews are, at best, an exercise in prediction. In practice, they are often an exercise in magical thinking.

During the workday, people aren't being constantly judged. They don't implement functions on whiteboards without unit tests, solve brainteasers out loud during stand-up meetings, or implement quicksort from memory. They do have to explain code to coworkers, but not to people who don't understand the problem space, the language, the background, or the constraints. These rarely-exercised feats of skill are valuable -- sales is valuable -- and our gut feeling is that such feats are somehow related to relevant job skills. But gut feelings are often wrong. And not every job is in sales.

And it's relevant to a job like sales. (That's unsurprising because a job interview is actually a sales meeting.) And many management jobs do have a sales aspect -- you have to justify budgets, sell work inside the company, et cetera.

But if explaining our work to outsiders were a particularly important or routine skill for programmers, we wouldn't be so bad at it. And, on average, we are bad at it. Because our actual on-the-job communication, which we practice all the time, is largely written and asynchronous, taking place on media like Slack or Github. It relies on plenty of job-specific shared knowledge, domain experience, and jargon, and it all happens in the shadow of a job-specific shared codebase that is supposed to speak for itself -- the whole point of software is to build something that works by itself -- but is also perpetually unfinished.

There are social skills that are important to have on a software team, but it's difficult to judge them in an interview. Interviews are staged events. Challenging a candidate to defend a resume in an interview is like asking them to do improv comedy, and selects for many of the same factors: Verbal gracefulness, comfort in the spotlight, the ability to seamlessly change the subject, and the amount of time spent in rehearsal. Good candidates rehearse their resumes. We get to write them ourselves, after all, and with practice we learn to design them with hooks that lead into our best material.

You want these people on your team.

Imagine that our interview goes like this:

---

Q: Can you implement a red-black tree?

A: I don't know. My Ph.D. is not in CS and I never actually seem to get around to reading the copies of Knuth and CLRS that I optimistically keep on my shelf. Nobody really wants to pay me to read about trees. So mostly I just use other people's trees, particularly the ones that are hiding inside Postgres and MySQL.

It would be fun to try to figure out how to implement a binary tree by asking you twenty questions -- it's one of my favorite party games -- but it will take a bit of time, and I'm in an interview and feeling nervous, so I'm not sure my odds of success are that high.

I did read on Wikipedia the other day that operations on balanced binary trees are O(log N) which makes intuitive mathematical sense, given that a branched structure with n levels will have 2^n leaves. So I guess balanced trees are pretty fast.

---

What do you do next?

I presume that, given that I've failed to answer the specific question, and demonstrated a degree of "slickness" and "force of personality" in the process, that you will ask me if I have any questions, shake my hand, send me out the door, inform your colleagues (including the one who referred me to your company) that I'm a NO HIRE because I couldn't remember the algorithm for constructing a red/black tree, and send me a polite rejection letter the next day?

Perhaps that strategy would have the virtue of being fair. But could you please get it over with during the phone screen? Better yet, could you make sure your recruiters never even email people who don't explicitly advertise CS degrees? Because I'd hate for you to waste a single minute thinking about me, and vice versa. Time is precious. If I find enough of it, I might even get around to reading Knuth!

[1] edit: that is to say, it has a factual answer if you ask the question and then fall totally silent. Which would be evil, of course, so in practice you and the candidate will naturally turn this question into a back-and-forth repartee, and it will reduce to the same exercise of unconscious biases as the vague question is.

(Sometimes it takes more motions, because Dash knows the docs for everything and sometimes doesn't get the context right, but that might also be driver error: the app is always politely telling me that I could learn to use it even better.)

Docs aren't always the best tool but it is good to have them at your fingertips.

patio11 is on to something when he suggests using your own codebases. Keep them all on your machine. Learn how to search them. (I use emacs and its various project-directory search utilities like Projectile and Helm, but there are other tools.)

If you don't have any Rails codebases to refer to yet, Michael Hartl is here to help you.

Your personal library is best because it comes from your perspective and with your memory cues. It also only covers use cases you have actually seen, which sounds like a bug but which is actually a feature. The problem with trying to use public docs as references is that they cover all the features that you will never use.

One drawback of your personal library is that it will always feel obsolete. This is a good thing; it means you are improving. Fix it up in bits and pieces where you can. Borrow ideas from the pages you Google.

There is a school of thought which says that you should use your public Github profile as your personal library. Having dabbled in this for a while, I now reject it. Do not write your notes for an audience larger than one. The amount of time you spend thinking "is it dangerous or embarrassing to record this line of code in my private personal repo?" should be zero. If there is anything worse than having the internet read over your shoulder, it is imagining the internet reading over your shoulder. Buy a big private Github account, use Bitbucket, or run a private server for your hacks and notes.

Take notes on everything you do. In particular, get in the habit of pasting the command-line things that you do into a cheat sheet. This is the beginning of devops wisdom. One reason why the advanced deployer does everything with a script (or Vagrantfile, or Dockerfile) is that the script remembers the steps for you and can be looked up later.

Web service software is not secure unless you patch it rapidly. There is no silver bullet. Last year there was a big security hole in Drupal, which we patched. Much like the ones that routinely turn up in Wordpress, which they patched. Much like the ones that happened, what, three or four times to Rails in the last few years? Which are like the ones they found in OpenSSL, which are like the ones they found in bash - bash, which is not supposed to be a web service! But which is nonetheless connected to the web in lo these many ways.

You have to watch for patches and apply the patches. Ubuntu gets six of them every week. There are tools that apply them automatically, or with one line of typing (which rapidly ends up in the autocomplete buffer, let me tell you), and server reboots are only needed once a week or so, but you have to do it. You have to spot the patches and you have to apply them. It is like brushing your teeth, with the occasional excitement of an urgent tooth-brushing emergency. It's mostly boring.

You must also have a plan to recover if a patch doesn't get applied in time, because these patches can be hard to write and can take several tries, and because you won't always be perfectly fast at getting your chores done. So you need to keep your family jewels away from the Apache server process, preferably in an alternate universe.

If you are a company, this stuff graduates from boring to "hard", because how do you know that the employee who swore to do the upgrades every week didn't forget for six critical days? But mostly it is just about patience and routine. Routine turns out to be surprisingly hard.

The symptom of any such problem is that email starts falling into the garbage, perhaps silently. But if you are watching your stats like a hawk (a costly and very boring hobby ) - or, much more likely, if your customers start screaming about the very-real high costs of lost email - you will figure that out within a few days, so it might not take more than another day to figure out how to get yourself off the blacklist (a manual process) and how to apologize to customers for the lost email (a manual process). But, if you value your time at in any way, your first encounter with that problem will be your last, because email services are cheap and easy. I have yet to pay for mine; in small quantities Mailchimp, Mailgun et al are free. Indeed, given that low cost, why wait to get burned before you stop playing with fire, even if the fire looks cute and innocent and warm right now?

[1] Actually, I'm lying: A much more serious problem which occurs at any volume is that email is another piece of the security perimeter. Even if mail servers had almost no configuration and a history of bug-free operation - which they do not, I am joking, and the joke is not very funny - one of the basic rules of security is to put as much distance as possible between your data and services which connect to outside machines. Mailgun is free in small quantities and runs outside your entire datacenter. The math kind of does itself.

$500, eh? Hmmmmmmmmmmmmm.

They could easily preserve LN for days. Dewars are impressive.

It's objects that are the problem, because they do not evaporate and they do not flow away. One of the worst is cloth, which tends to be wrapped around your skin, so when it gets soaked in LN it promptly gets super cold and then sits there burning you while you try to get it off. I got a tiny splash on one of my socks once. Fortunately it wasn't a big enough splash to do more than sting a lot and teach me never to splash LN on my clothing again.

And, as you point out, the other problem is that protective gloves are essential for handling cold solid objects, but very dangerous to have on your hands when touching the liquid. Which means you need tongs! Long tongs, so that your gloved hand stays safely at one end while the other end is fishing around in the nitrogen.

In a world where millions of Chinese programmers have to use keywords written in a foreign language who am I to complain?

There is little reason to expect that reforming POSIX spelling is going to be any more successful than reforming English spelling.

http://www.kalzumeus.com/2014/11/07/doing-business-in-japan/

(I could pull an answer to your question out of this -- hint, search the page for a dollar sign -- but if you're reading "out of curiosity" you should just get some coffee or something and read the whole glorious thing, because the number is useless without the context, and the context is very different from the USA.)

Others have already pointed out that our geography is different. But that might not even be the real problem.

I am a fan of trains, but I live in Arlington, Massachusetts, which is not on Boston's rail-transit network, even though the Red Line subway terminates within half a mile of our town line, with a conspicuously available right-of-way leading straight from there to our town center. Isn't that odd?

I was sad to learn that Arlington used to have streetcars. They went through town and extended at least three towns further out. They were torn out in 1955.

I was even sadder to learn that a Red Line train station in Arlington was explicitly planned back in the 1980s, but...

That plan had been supported by the Town of Lexington, but was scuttled by fierce anti-urban sentiment in parts of Arlington.

This quote from Wikipedia (https://en.wikipedia.org/wiki/Red_Line_(MBTA) ) matches what I've heard from local residents, though it's a bit more diplomatically phrased.

So I've got a hypothesis: The USA's once-excellent rail network was deliberately taken apart in response to (ahem) "fierce anti-urban sentiment", a political force that remains strong. Consider this article from last week:

http://www.newgeography.com/content/004788-voting-with-your-...

The most recent “solution” was for the city of Lancaster to propose shutting down its MetroLink rail station in order to prevent lower income people from traveling in from other parts of Los Angeles County.

If you want to "fix the problem" of connecting US cities and towns via rail, your first challenge is to convince the cities and towns to stop openly sabotaging your "fix".

(Corollary to my hypothesis: In the USA, rail proposals of the last twenty years have focused on long-distance, high-speed express intercity travel because such routes don't stop in the suburbs, and therefore don't disturb suburban voters in their splendid isolation. Of course, by focusing on long-distance point-to-point travel, rail throws away most of its advantages relative to flying.)

U.S. employees are also trained on the job. The difference is that it's a succession of jobs, separated by job searches and interviews – an inefficient and unreliable process.

Statistics show that the average U.S. worker put in 1788 hours per year in 2013. The average for Japan? 1735 hours per year. Neither of these represent world-class efficiencies: The Germans and the Dutch, for example, manage to run their modern economies on less than 1400 hours per worker.

http://stats.oecd.org/Index.aspx?DataSetCode%3DANHRS

The USA does have a significantly higher per-capita GDP than Japan, but the Swiss are higher still, and only work 1588 hours per week.

https://en.wikipedia.org/wiki/List_of_countries_by_GDP_(PPP)...

(These are glib analyses, of course, because averages lie in various ways. The fact that Qatar has three times the per-capita GDP of the USA should give one pause; per-capita GDP is not the same thing as "quality of life of the average resident".)

The idea that iPhone manufacturing is somehow "foreign" to Japan is pretty funny. Mobile phones are international products, built with parts and machines and expertise from around the world, certainly including Japan:

http://www.cnet.com/news/japan-manufacturers-said-to-gear-up...

Yes, many phones aren't assembled in Japan these days, but they aren't assembled in the USA either. The Japanese can still field some of the greatest electronics engineers on the planet, but they work on higher-leverage problems than final packaging and assembly.

I have nothing against the simple stats -- why waste time on complex pseudoscience when basic pseudoscience will do? -- but the risk is that we'll design a stats page by adding numbers one at a time, in laziest-first order, until the screen starts to look cluttered, at which point we'll pick the most promising pattern we've spotted so far and start trying to optimize it. This is a great way to generate Powerpoint slides with lines that move up and to the right, and a lousy way to measure value. The micromanagement of statistical placebos is the occupational hazard of our age, and we should try to push back.

It's easy, too easy, to game my average-points ranking. I should contribute only popular thoughts to popular posts. I should assiduously avoid commenting on anything that's not on the homepage, or replying to people who are not near the top of a thread. I should make sure to comment within the newly-arrived-on-the-home-page time window, which is presumably now measured in milliseconds. I should certainly avoid giving advice to people on Ask HN.

That's no way to live.

The engineering team probably spent some time running tests and scribbling on whiteboards, trying to prove that the boat wasn't going to sink. In hindsight, they should have just sounded the klaxon and started handing out life jackets, but you know what they say about hindsight. And there are lots of reasons why the typical engineering organization struggles to accept the inevitable and call for an evacuation. Nobody likes Cassandra. Everybody wants to be a hero. Didn't you say this boat was unsinkable? It's hard to get all the decision-makers into one room. The show must go on. It isn't obvious that this complicated problem leads to our certain doom. Et cetera.

The key to making these things go smoothly is the Chaos Monkey, a.k.a. "conduct constant drills of your emergency responses". If you don't rehearse the response, you shy away from trying it. AWS halts or reboots EC2 instances all the time, and lo and behold, when it comes time to reboot all EC2 instances they don't flinch. Or they flinch less visibly, anyway.

I found that, once I restricted myself to the features of static pages, the security risks of Wordpress were a lot less scary:

- You can't hack form submissions if the site doesn't have any forms on it.

- If you're going to require SSH to publish new pages, you can require SSH tunnels to log in to Wordpress or access any admin pages. (I should write up my nginx config for this.)

- If you were prepared to make every site update require a Git push, you can surely afford to disable WP's very scary self-update-in-place feature and perform WP updates from a development server instead.

- A WP site that could be usefully replaced by a static site is vulnerable... how, exactly? Static sites don't accept credit card numbers. Customers can't even log in, so they won't type in their darkest secrets even if they wanted to. Employees can be told to follow rules like "don't use your Gmail password for the corporate WP site" and "don't type anything into the public publishing engine that would cause an emergency if it were published to the public."

The biggest risk is denial-of-service and defacement. Restore from your tamper-proof offline backups, which you need to have anyway. There are probably fifteen different services you could use to be alerted when the website changes unexpectedly or starts serving up malware.

Of course, static websites are faster. Until you turn on Cloudflare's free plan, which makes everything faster still.

The small-caps links are inline references to other sections of the same book; their distinct typesetting distinguishes them from mere text.

Because everything in the table of contents is a link to part of the book, these links are not set in small caps or otherwise distinguished — that's a potentially confusing design choice in theory, but I can't complain because it was obvious enough to me from the context that I should try tapping something.

The diamonds are outbound links to other sites. Given that this is a coherent book and not a collection of random posts, this distinction is handy: while reading Butterick, I am more likely to click a link to more Butterick than to click an outbound link which will cause me to lose my train of thought.

I'm also not sure this is a counterexample. It's just the opposite perspective. From the perspective of a parent, a three-year-old becomes a thirteen-year-old with terrifying speed. A cell biologist would note that both kids are built from the same parts, many of which are also shared with killer whales and the front lawn.

My examples are all easy to flip in this way. The most remarkable feature of iOS is that it is directly descended from the twenty-five-year-old Next system, to the point that it carries all those cute little "ns"es around.

Change is constant, but provided one escapes the traps of lock-in (oops, Adobe Flash, dang!) and resists the whims of fashion, the change can happen slowly and piecemeal. If a new Golang library is important enough, it can always be ported to C later for the benefit of one's great-grandchildren.

The dependencies that you need to avoid are runtime dependencies, the kind that can disappear overnight. Does my deployment depend on Rubygems or NPM being up? Did I accidentally build in a hard requirement for Google App Engine? Did I use a licensed piece of software whose license could be withdrawn overnight? Is there only one person who can even read my fancy-pants source code, and might that person suddenly decide to become a guru and retire to a distant mountaintop with no cellular access?

But there's no sense in fretting about what might happen on a five-to-ten-year timeframe. Face it: In ten years, the code you write today will look old. Using Java won't save you. The fact that Android is based on Java doesn't mean that ten-year-old Java apps support Android in any meaningful sense. Ten-year-old Objective C code is stale: It doesn't support iOS, it doesn't use new features of Mac OS. How do you even know which Python will be most popular in production in five years, Python 2 or Python 3?

Your code will evolve over the next N years, and if Go spontaneously implodes -- a very unlikely event at this point -- you'll do what the Docker folks are going to do: Keep using it for months or years while you port it to whatever comes next.