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.

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.

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.