Shifting gears

When I started this blog, I wanted to write about a whole variety of things. Lessons I learn, projects I work on, reviews of software that I use. However, over the last 6 months however, there have been just a couple of posts that have gotten the most (read recurring) interest.

The one post that has by far been the most interesting is the one on building a web app with Nodejs. Initially I thought the popularity of the post was because of some SEO mojo due to its popularity on Hacker News and the really awesome naming (put 5 technology product names in the title of any post and you might see the same results).

What I didn’t realize is that the post was really helpful for people. An average visitor spends ~5 minutes on that post alone, which is pretty high if you’re familiar with the engagement metrics on the web.

So, moving forward, the focus of this blog will be around technology/programming lessons based on things I learn myself. This will also help me in my journey. So, if you want to learn some new tech skills or two, hop along and hit the subscribe button!

You don’t need a license to create

There’s been much debate about what Paul Graham said or meant in his interview with The Information. Since then, many have written about how sexist or discriminatory Paul sounds or not. Examples are here and here.

All in all, I don’t think Paul meant what his comments sounded like. However, given that not everyone has the full context behind YC and how it evaluates startups, lot of people are making hay out of nothing.

In all of this, we’re missing one simple truth. No one needs a license to create. You don’t need to be any age, creed or sex to make something people want. Yes, existing institutions (e.g. YC) may have a hard time finding a pool of entrepreneurs which represent the global population entirely. However, that doesn’t mean they believe that’s what the world *should* be like.

This was just a simple case of mis-communication. Read Paul’s response to understand why.

30 percent coder

For the first time in my life, I can legitimately say that I spend at least 30% of my work time coding.

At first, it was just through my side project, which I started building with a couple of friends. It was an excuse to learn how to code again and I have to say – it’s been a great experience. We released v0.1 (really, a proof of concept) a few weeks back and are already working on the beta product now.

However, what’s been really awesome is the transition I’ve been lucky to make at work. I work on the Business Operations team at Dropbox, which is a pretty unique group. Almost everyone has *some* technical background – at least enough to be taken seriously at a tech company. What’s interesting, though, is that the company and the group has created a way for anyone to come in and start adding value without being a burden.

When I wanted to run some experiments for our Business product’s site, and there weren’t enough engineers to build it, I was encouraged to just do it myself. It wasn’t just all talk. When I got down to it, I had my local VM running in a couple of days with very little engineering input and had my first production push under a week. I went from being a strategy/operations guy to coder within a matter of a week. Not only did the engg. lead, who helped me, not freak out, he patiently guided me through the process and helped build my confidence.

That was about 2 months ago, and by now, my team jokingly refers to me as the “resident engineer”. I might not be anywhere close to the level that the awesome engineers at Dropbox perform at, but what’s been amazing about this journey is the willingness of the company and my colleagues to take risks with people. At the same time, the company’s built some awesome systems (really, from being a non engineer to pushing code in under a week is huge!) that help anyone come in and build great stuff, if they want to.