Vishnu Gopal

The title isn’t original, but it’s apt and describes my feelings exactly. Bulleted, and also referred to as Vishnu’s Commandments for Fixing Code:

1. Fix The Fucking Problem (hereafter FTFP)

   When you’re faced with a bug, a calamity, a loss of limb, you solve the problem. Don’t worry about its causes, its probable antecedents, which commit broke your painfully arranged view of the multiverse or whether you’ll earn a PeeEtchDee by writing a paper about good software engineering practices. Instead, you FTFP.

   Only after you’ve FTFP, shall you think about anything ancillary. Only afterwords shall you blog or tweet about it or submit it to our humorous overlords. Capish?

2. Next, FTFP as if your ass is on fire.

   Downtime sucks. If a marginally large system used by a non-trivial number of users (by which I refer not to your blog which your mom and your imaginary girlfriend reads) goes down the rabbithole, a lot of people will complain. If you work for Initech, Lumbergh will cluck his tongue and hand you a pink slip if you mess up too often. Forget nine-nines of reliability, if you manage a month with just 5 mins downtime, it’s great.

   I’ll also extrapolate this from TDD: “Write a test, write the minimum amount of code for the test to pass, refactor, write more tests.” becomes “Figure out the problem, write the minimum amount of code that fixes
   the problem, refactor, find more problems.”

3. Log. Write logs to Disk. Backup & rotate Logs.

   In any after-action report, you’ll want to figure out why the Problem happened. What went wrong. For this you need logs from when it happened. Often you’ll notice that it’s a periodic bug which slowly got worse as your system added in more users, so you’ll want to figure out exactly when it happened, and when the issue escalated. For this you’ll need to log properly and backup those gzipped logs. Thumb rule: for the first nine months of any production system, logging should be enabled with the maximum possible verbosity. This includes connected systems, like for example, Database Logging.

4. Use Git already, nitwit!

   It’s pretty much what everybody should use. Easy, quick code commits and can even serve as a quick and dirty deployer too. Git allows you to hotchpotch solutions in case of emergencies. There will be instances when you want to short-circuit every code review check and just deploy the thing goddammit and nothing beats Git, for now.

5. Use an automatic deployment tool.

   Your deploy should be just one command, or a click of the button. Hooking up before-commit hooks is okay as long as it doesn’t take an eternity.

6. Make pretty downtime notices so people know you are at least trying.

   Being apathetic sucks. Giving an impression of being apathetic when you are working hard to save your application sucks harder because of stupidity. So don’t be stupid. Communicate. Make twitter work for you or for the old-fashioned, have a mailing list or an RSS feed. Your blog shouldn’t go down at the same time as your site so keep it on a different server—wtf are you doing writing a blog app anyways—outsource that to people who know better.

7. Learn the ins and outs of your deploy OS of choice

   It’s not enough to be a Gee Whiz programmer. Learn your OS inside out. If you’re on *nix (like real men) then this involves figuring out what to do when your load average goes through the roof, your SQL engine hogs CPU, your hard-disk fills up or your webserver restarts. Learn about commands like: top, iftop, iotop, uptime and the entire /proc magic filesystem. It’ll help you diagnose code and issues. For blacker magic, learn about strace and dtrace and how to debug difficult issues. All this comes later though—remember the golden rule: FTFP, so the first take should always be to Google your error.

8. Don’t put all your eggs in one basket

   Do trust in Murphy, he’s eternally right. Things will fuck up. Instead of preventing it, plan for contingencies and try to recover from them fast. Have scenarios where bad things happen to your application. Have a load balanced implementation the first thing for chrissake! Have a DB in a master-slave configuration the instant you can afford it. Have a system where provisioning servers doesn’t take days. Move as much infrastructure as you can to the cloud where you don’t have to maintain it directly.

9. Delegate the Debugging

   This might be harder to do because you’ve got to pump up your adrenalin and stay in the zone to figure out problems and implement quicker solutions, but often, three or four helping hands work much better at solving problems—especially when other people can help you cross-reference data to try to come up with probable cause. Remember, speed is key.

   Surround yourself with people who are smarter than you too. That helps to negate your stupidity. Own up to mistakes and implement solutions fast.

10. Have a Staging Server (or Replicate Production as closely as possible)

    The worst problems are those that happen only on production systems and can never be replicated in development. Remember: OSX is not Linux, minor version differences often introduce incompatible interfaces (I’m looking at you, Rubygems and PHP) and stuff breaks when you add something new without testing it on your deployment OS of choice.

    If you are making any drastic changes to the architecture, test in on a staging server (or if you can’t afford it, a password-protected subdomain) in live conditions before switching, it’ll save you loads of trouble.

11. Prevention is better than Cure

    Do TDD or have a good test suite. Stuff will break far less often then. Educate your coders to have decent S/W engineering practices. Indent code and name variables uniformly. Raise exceptions and use assertions within your code. Use transactions too so when stuff breaks it doesn’t affect a lot of other important elements. Learn how to use a Queue and how important that is in modern production systems. Don’t abuse an RDMS for tasks it wasn’t meant for. Learn about newer key-value storage DBs. Beware of caching—it introduces subtle errors and problems, but learn to love it too, without it, you’ll never scale. Write readable code and document it both within and separately.

Share this:

• Twitter
• Facebook

Meera’s new blog is here: meerarnair.wordpress.com. (She also has a twitter account btw @meeranair).

Background: Presentations that include female nudity and references to porn in professional presentations. The first incident occurred at GoGaRuCo the Ruby conference in April, the second and far more blatant one at the Flashbelt conference just two days ago.

This is my take on the issue, and my personal experiences with these kinds of incidents.

Incident one: I had gone to the Bangalore FOSS.in conference about two years ago. An extremely attractive lady from linuxchix came up on stage to speak on The Black Art of Makefiles. As has happened many a time before to many a speaker’s laptop, hers refused to play nice with the on-screen projector and the slides just wouldn’t come up. Yes, probably a screen resolution mixup. What was unusual though was the ten guys who rushed up on stage and started working on her laptop. They tried for a minute or two to fix the problem (without success) before the lady eloquently managed a few keystrokes in. And voila, the slides came up and the crowd dispersed, sheepishly. Yes, the lady knew best—it was her laptop after all.

Incident two: One of my friends is studying for her MBA at a good institute where companies come up to place people for summer internships. An interesting statistic: 80% of people who got placed in high-profile companies were girls, and a reputed technical MNC only gave out internships to girls. I theorize that this is because as a rule, girls sell products much better than guys.

Fact: There are subtle (and not) gender differences in the technical community that’s visible every day. While most often this is genuine discrimination, sometimes (as in incident two) it’s biased towards women too.

Fact two: Not all discrimination is deliberate. I’m pretty sure the Ruby presenter was just trying to be “edgy” (Ruby is much more conducive towards such non-mainstream behavior) but ended up offending the women in the audience. I’m not sure many women realize this, but men do not have an internal radar on the things that offend women – this is a general extension of the “cluelessness” that is often attributed to us, albeit with more serious consequences in this case.

Whatever the case may be, there’s one solid fact. We genuinely need diversity in the technical community – a broader opinion and insight on every topic just leads to a better community and this is true however cutting-edge it might pretend to be. Most of the people do want to encourage this diversity too and not make women uncomfortable at formal presentations and in a crowd which is >80% men.

One suggestion. I know women are not confrontational, but early intervention will help – if you feel uncomfortable, speak out, and the earlier the better. If you are in a mailing list and there’s a sexist troll, speak out and say you are not happy. Some men do listen (and those men are usually the ones who are in charge).

I’ve got to admit the blog posts and news coverage have made me think on what is appropriate behavior in public. Some people want to portray conforming behavior as a dampener to creativity but that’s hardly the case – you always follow some sort of rules (for e.g. imagine a guy taking off his clothes on stage – I’m certain the 80% won’t be amused). Creativity within constraints is a challenge and if you want a discerning minority to listen in and come up with suggestions, make sure your slides do not offend too.

One more thing—As many women have pointed out in the Flashbelt incident comments, it’s not the bawdy humor that’s the problem—it’s the context. If you want an analogy, imagine yourself as the only person in a crowd of women all laughing at a joke about how size does matter after all.

So I was a very early Internet user. Not so early as Tim Berners Lee, but early enough to see Internet access begin in India – those dialup modems were excruciating: they promised much but delivered little. I remember a service early enough in the Web 1.0 era that allowed people to register domains for free (yes, without paying a buck). These guys (I’ve forgotten the name) made money by framing the site contents and delivering flash and scroll ads up top. Needless to say, they quickly went out of business. But I remember I had a vishnugopal.com registered with them way back then.

Since I’ve been “alive” on the net for close to ten years now, I’ve left traces under many different identities. Very early on, it was uncheckedramblings, which was the name of a blog that I made at blogspot.com – vysnu.com evolved from those humble beginnings. Concurrently, my primary identity on the web was thehitchhiker and the necessary variants that had numerical prefixes, suffixes and substitutions to it. My Yahoo ID until a couple of years ago was thehitchhiker_123. I had another alias during this time created for shady purposes. I used q— to write unconventional stories. Then (in a fit of originality) I combined that ID with thehitchhiker to create QHitcH (often spelled all lowercase as qhitch). That is still my Skype ID.

So just to recap, until now I’ve had four identities on the web. Till recently, I maintained my portfolio site at vish.in, my blog at vysnu.com and my twitter account was named vishmaker.

While it’s nice to be creative, it’s also nice (and SEO sensible) to be consistent. And what better name to brand than your real name? So it’s vishnugopal everywhere from now on.

Inspiration: The excellent Securing Your Online Identity article, an extract below:

Ideally you should implement one consistent online name that can be used across many different platforms. It's best if your online name is the same as your offline name, but you may find it necessary to make them different for certain reasons. You may also decide to use a different name for your business presence and your personal communications. Generally the higher the consistency you can achieve the better.

via Securing your online identity | creativebits.

Aside: It’s a sad fact of the web that none of those early avatars are visible now. It’d have been nice if HTTP behaved more like source control – web.archive.org didn’t consider any of my sites important enough to store.