We didn't have iPhones in 1995, but television filled the same role. The result was no better. It was probably worse.
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.
but you can't carry your TV around like cell phones. I still feel the problem is worse now a days. Also when you are watching TV with someone, at least you're watching the same thing together, which often spurs conversations. Now everyone is fixated to their own phones, each person has no clue of what other people are reading on their phones.
The stakes are high, so I'm going to be blunt: This is terrible advice. [1]
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.
DON'T DO THIS. You are going to put this off for months. And every year you put it off will cost you in the end.
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.
DO THIS TODAY, I BEG YOU, YOUR KIDS WILL THANK ME ONE DAY.
---
[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%)
Weighting all those expense ratios by their fraction of the portfolio, I compute that I can achieve an overall expense ratio of 0.09%. So I'm saving 0.09% compared to letting Vanguard do the work.
[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.
Like I said, this is nitpicky to the nth degree (and in full disclosure I advised my wife to do a target fund when she started investing). You can do much, much worse than a target fund and hardly better.
That said, I've encountered many 401k plans over the years where the target funds have very bad expense ratios (.35 or higher). Meanwhile there will be a total market fund and a bond fund sitting closer to .08 or .09.
I personally, had a 401k plan that had the choice of a target fund at .28 expense ratio or a fidelity spartan class total market with NO initial investment requirements. I was able to invest at 0.07 expense ratios when I had less than $500 in a retirement account.
So, if you have the choice at a Vanguard target fund, yeah you aren't going to do much better than that. But especially when someone else is limiting what you can invest in, it can be advantageous to go with bare index funds.
I don't know OP's country of residence, but I believe Vanguard mutual funds are not available in the US - they're not available in Canada at least. Even if one has access to the Vanguard retirement funds, it's still useful to understand why a portfolio works over the long term (or not). This can be particularly useful when the markets plunge, as they did very recently.
I've read both Four Pillars and Random Walk; I refer back to the former much more often than the latter. But both are great books.
In tandem with looking up the data, I also recommend broadening your social circle by meeting a former alcoholic or two. They're not hard to find. Alternatively, you can read their memoirs, which are even easier to find.
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.
My theory continues to be that the music industry is just unlucky. They entered the internet era with a product that was perfectly positioned to be annihilated by Napster, iTunes, and YouTube.
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.
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.
You certainly can get clients through email, and I can think of no more valuable skill you could practice than the art of composing a really good email to a consulting customer who lives twelve time zones away. It is not especially difficult to earn $500 per day with that skill, plus the skills you already have. Algorithms, shmalgorithms.
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.
It's highly relevant to getting a job on a software team, but only because most teams are assembled via interviews, and verbally relating stories from your past in a face-to-face meeting is the most effective interviewing technique.
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.
I would say the whole point of software is to build something that people can use. If someone builds a module, but can't tell me how to use it, it's not of much use to me.
Oh, but surely they'll write documentation? Programmers, by and large, seem to suck at that too, which is why we have tech writers. But somebody still needs to explain to the tech writer what's happening! And only a few companies seem to carry tech writers for internal only products.
To put it simply, if I ask somebody how their code works and they say "Go away for an hour while I write documents" I think I'd rather not work with them. Or worse, they ask me for help debugging but can't tell me what they're trying to do. No thank you.
Your questions are good and relevant ones, I agree. Let me rephrase them a little:
"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.
Quite a few RIT grads have come through my employer's engineering teams. There seems to be, or have been, a program there in "network engineering" or something, which places a big emphasis on practical systems architecture and debugging. Its grads emerge full of stories about how hard it is to assemble and debug all the physical interconnects between the network switches in the server racks that you have to assemble before you graduate.
If the question is an algorithms type question, then there is no ambiguity, and either the interviewee answers it or they don't.
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!
You may think you're doing the candidate a favor by offering to handwave away the details, but the vaguer question might actually be worse. "Can you write a correct implementation of an AVL tree on this whiteboard, in any programming language, in the next thirty minutes" is a terrible interview question, but at least it has a factual answer. [1] "Can you riff on the subject of serializing a binary tree" is an open-ended question that will inevitably be graded on an imaginary curve. And the first rule of human psychology is: When you're asked to grade people on an imaginary curve, your intuition spits out a decision that is built on unconscious bias.
[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.
Let me get the plug in first: if you are on a Mac, try Dash, the app that looks up docs for you. I have it mapped to a keystroke in emacs, and I can sometimes park the cursor atop, say, the word 'render' and look it up in one motion.
(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.
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.