[Edit: I changed the CNAME record for the root domain to be an A record pointing to the Posterous IP address (currently 184.106.20.99). This seems to be fixing the problem. However, I don’t like that solution because if Posterous changes its IP address then everything breaks. Also, I feel a bit stupid but I’ll leave this post up because it may be useful to someone else.]
A few months ago I decided to point diegobasch.com to my posterous blog, which used to be located at dbasch.posterous.com. As instructed by Posterous, I changed my Namecheap dns settings to look like this:
I use Google’s DNS servers, and I’ve never had a problem accessing my blog on Posterous. I went ahead merrily and kept dumping my thoughts, dry humor and sometimes vitriol into my blog. In the months since, I had a few blog posts that went somewhat viral on Twitter and Hacker News. Interestingly, I received many comments from people who tell me “your blog is down” or “I’d love to read your posts but I cannot access your site.”
At first I thought it might be temporary glitches on the part of Posterous or Namecheap, but I confirmed independently with both that everything works as it should.
Yesterday I asked Twitter to help me diagnose the problem. It turns out that the problem seems to be with Comcast, and perhaps other ISPs. Says @cavorite:
@dbasch It seems that the problem is with Comcast’s DNS servers, “dig @75.75.76.76 diegobasch.com” yields SERVFAIL.
I started researching Comcast DNS servers on my own.
If you read this post, many people complain that Comcast seems to be hijacking requests for non-existent domains to show whatever they want. However, I changed my domain months ago. Comcast should have taken notice by now.
Two conclusions:
1) Comcast DNS servers are broken.
2) DNS in its current form is broken as well. It wasn’t designed to be used by the current internet. Furthermore, a particular ISP can decide to use its DNS servers as a mechanism for censorship.
I believe that OS makers should give people an option to choose among several DNS servers during the installation process, and explain why.
[Originally posted on July 25, 2011 on the IndexTank blog, now down. Reposting it here so I don’t lose it.]
If you are reading this there is a chance you may not know who Steve Vai is. In my opinion, he’s the owner of the most gifted musical brain in the world. You may not like the style of music he plays or his guitar pyrotechnics. However, there is no question that most bands would kill to have someone like him on stage. David Lee Roth and Frank Zappa surely agreed with this statement. Here’s what Steve himself has to say about his audition with Zappa:
Now imagine for a minute that this audition had taken place in an office, and that Frank had told Steve: draw this song on the board and explain to me how you’ll play it. Well, you get my point.
There’s a lot of superstition in engineering interviews, and here’s where I need to pull my credentials. I’ve been interviewing software engineers since the 90s. I’ve interviewed hundreds of them if not over a thousand. One thing I can say with 100% certainty is that making someone code on the board won’t give you any information that you couldn’t get from a phone conversation. You won’t learn if the person is awesome or if he/she could build anything to save their lives.
The point of an engineering interview is to figure out if you want to hire a person or not. Obviously you want to minimize false positives and false negatives. Many companies tend to focus on eliminating false positives at the expense of having too many false negatives. This is because hiring the wrong person could be extremely damaging to a company. This is all well and good in a market where there is an abundance of qualified candidates. What if your system yields 80% false negatives and you can get one interesting candidate per month? Not hiring anyone is also extremely damaging. For a startup especially, not taking risks means dying.
The holy grail of interviewing is to remove noise. Ideally you want to evaluate a person’s capacity to perform their expected duties. Now, think about the last time you wrote code on the whiteboard at your current job. In my case, let me think… NEVER! Diagrams, architectures, design, etc. Code? F-NO!
Today, here are the things that I look for in a candidate:
1) Did he ever build anything? A Github account (or any other public code) is a plus. 2) Can he communicate? I want to see a blog and/or a Twitter account. 3) Does he live in the past? A good LinkedIn profile is worth 1000 resumes.
Past that barrier, of course I want to see for myself. I’m not saying that a software engineer candidate shouldn’t code at an interview. Far from it.
When you come to an interview with IndexTank, bring your laptop. Be ready to sit down and create working code. You don’t have a laptop? That’s a handicap, but not a big deal. You can use one of our Macbooks. Let us know if you want vi, emacs, Eclipse or even TextMate on it. Java, Ruby, Python and C will be available.
One thing we won’t do is ask “aha” brainteaser questions. Sure, being able to get four dudes across a rickety bridge is a proxy for a high IQ. Big deal. I know lots of people who are awesome at chess, Sudoku, etc. but will never hack for 48 hours nonstop because they are dying to see something working. Join the Triple Nine Society for example and you’ll meet some of them (there are great coders there too).
Over the years software companies have developed a cargo cult of interviewing people for raw intelligence and the ability to think quickly on their feet. People, get with the times. Teach your engineers how to run an interview, because it’s not trivial. Remove noise. If you don’t do all this, do not complain that it is a tough market for hiring engineers. Also, do not make fun of people who are not good fits for the job.
At this point I could go into many colorful anecdotes (e.g. my terrible experience interviewing at Netscape in the summer of ’98) but I won’t. One final word:
I sincerely apologize to the people I interviewed in the past five years who had to code on the whiteboard. It’s not happening again 🙂 Come chastise me on Twitter
I just read this platitudinous article about a keynote given by the founder of Evernote, in which he says that *you* shouldn’t do a startup:
I’ve narrowed it down, really boiled it down, to one core piece of advice. If I can only say one thing, and I don’t know you any better, it’s: don’t. Don’t do it. Seriously.
My first thought was: “who is this guy to tell me what I should or shouldn’t do?” This sounds very disingenuous to me. It seems to me that Phil Libin thinks he’s got the right stuff, so he did a startup and he’s doing well. The rest of us probably don’t have what it takes, so we should go work for the man or whatever.
You won’t find any advice in this post. It’s just one of my usual rants. As you may know, I’ve done a startup. A successful one, by all measures that matter to me. We built a product, we had a great team, happy customers. We had a good exit and we made a fair amount of money. I like money. Money is good. Do you like money too? We should hang out some time.
Still, startup life mostly sucked. Making money is nice, but it’s neither necessary nor sufficient for having a fulfilling existence. When people ask me if they should do a startup, I tell them that I have no idea. What the hell is a startup anyway? At this point it’s become of those diluted, subjective terms like “freedom” or “happiness.”
Do you want to change the world? In that case what you want is a revolution, not a startup. Good luck with that. Do you want to be rich and famous? There are a plethora of ways. Do you want to build cool stuff? You can do that while working for The Man, or as a hobby.
I personally never liked working for big corporations, and that’s the reason I started my company in 2005. I’d worked for a few BigCos in my time, and it sucked. Come to think of it, it sucked even more than running my own startup later on. Still, I don’t know if I’ll ever do a startup again. If it do it though, it will be for the thrill of the game.
Phil says the only valid reason to do a startup is to “change the world.” Ok, in that case we’d all love to see the plan 🙂
I’ve been working in the tech sector for over two decades now. That means I’ve had more bosses than I can remember. The ones who left an indelible impression in my brain were in the extremes: either great or horrible. There are many books written about how to be a great boss, for example Managing Humans. Today I’m going to take the contrarian position, and tell you how to be horrible at it.
Why is this useful? I don’t know, perhaps you were such a great programmer that you were promoted. You reluctantly accepted your role as a manager, you hate it, and you want out. Of course you could figure it out with your superiors, but let’s assume you’re an introverted nerd with zero social skills 🙂 Seriously, here is a list of things that would make you a horrible boss. Do not try these at work!
Talk a lot, do not listen much. This trait would make you an annoying person in real life. You know the guy or gal who cannot stop talking about his/her own world: “enough about me, now let’s hear what you think about me.” As a manager, this is a cardinal sin. Why? Because unlike your friends, your direct reports won’t usually call you on it. You will have a self-reinforced view of what’s happening to them, and they will grow alienated from you. “The boss is out of touch.”
Be patronizing. Tell people how to do their jobs, and explain the obvious many times. If you were promoted to manage an awesome team, there surely will be stars who know more about their jobs than you do. The tech industry is not an assembly line with lots of turnover. For example, you may be managing a senior software architect with ten years of experience. If you ramble about how it’s important to “remember to design for scalability” or to “always consider security,” it will reflect poorly on your ability to trust him. My father-in-law was a successful manager for a pharmaceutical company for most of his career. He puts it this way: people become what you expect of them. If you treat your direct reports like children, that’s how they will act. Â On the other hand, if you place lots of trust in them from day one, they will be compelled to prove that they deserve the trust.
Be as cryptic as possible, never direct. Another cardinal sin for a manager is to not tell people what she expects from her reports. Expecting people to read your mind or learn things by osmosis is a terrible idea; to make things even worse, criticize people for not doing what you knew you wanted but never expressed. If you want to take it up a notch, go behind people’s backs and talk smack about them to your peers or superiors. At that point your reports will have no recourse, because you are their proxy to the upper strata of the organization.
Encourage bureaucracy, and demand visibility into everything. If you’re a horrible boss you probably don’t find too many people worthy of your trust. Never fear! The solution couldn’t be easier or more time-consuming: ask them to document every little thing they do. If they ask why, the answer is “because I need to know.” What if a senior executive asks you about the current status of the Lisp rewrite of FizzBuzz, and you don’t know it was delayed because there’s a temporary shortage of odd numbers for testing? Obviously you’d look like a clown if you said: “I don’t know, but I’ll ask my team and get back to you in a few minutes.“
Show them who’s boss. If there is one thing that’s proven to demoralize a team, it’s a boss who constantly reminds them he’s in charge. There are limitless ways to do this, for example:
Tell people to do things without explaining the rationale for them.
Have weekly status meetings even if there is nothing new to say, or if it can be said over email. In Peopleware,  Tom DeMarco says this about weekly status meetings: “though its goal may seem to be status reporting, its real intent is status confirming. And it’s not the status of the work, but the status of the boss.”
Punish people with menial tasks (“hey senior engineer, go make copies of these handouts because my time is too valuable”). Bonus points if you do this in front of others.
Don’t learn about management. After all, you already went to school for programming or whatever it is you do. It is obvious that your experience doing X qualifies you to manage people doing X. Why waste time taking classes or reading books?
At this point many of you may be thinking “hey, you’re describing my boss to a tee!” in which case you should be updating your resume and your LinkedIn profile.
I’m lucky to work in Silicon Valley, where these types are relatively rare. There are not very many Bill Lumberghs or Michael Scotts around here these days. In other industries, they are probably still the norm. However, there was this one time of rapid growth in the late 90s when the rising tide would lift all types of idiots into management. I’m not going to talk about these characters and how they destroyed companies, morales, and souls. Instead, I’ll re-read this post. Then I’ll go back to think about how many of the above sins I have committed in my career, and keep this post as a checklist. If you report to me and you see me doing any of these things, please call me on it. If you let me get away with it then I will end up like Bill Lumbergh, and my life will suck as much as yours:
