New year resolutions

I’ve written about habits in the past. Specifically, how hard they are to form and sustain. At first, I thought it was because I wasn’t measuring my habits and progress on a daily basis. I was unhappy with all of the habit tracking apps on mobile. So, I tried using plain old Google Sheets to record habits. That didn’t work either.

After several starts and spurts in the last few years, nothing has really stuck. I’ve come to realize that, for me, forming new habits has little to do with measurement.

In my personal case, it has more to do with not letting perfect be the enemy of good. I always start off on the deep end of the pool. I’ll write out my ideal list of habits, and try to hit them all from day 0. Hah. No focus or prioritization.

So, this year, I did something different. I wrote down 8 habits I wanted to form this year. Then, I stack ranked them, and decided which ones were “must do” vs. “good to do” vs. “nice to do”. This whittled the “must do” list to just 2 – exercise and meditate.

This took the pressure off. With just 2 must do things to do every day, everything else was gravy. Now that I look back, January was the most successful month for me in terms of sustaining these habits.

February was less successful (10 days of exercise and 5 days of meditation). I let work distract me from the daily routine. March will be better.

Setting up SASS with Express

Over the last few months, I’ve been using and getting familiar with SASS at work. I had experienced some benefits of it earlier as well but not to the extent to which I did more recently.

There is absolutely no reason why anyone should use pure css anymore when things like SASS and LESS are around. They are much easier to write in and comprehend because of the nested structure. There are many other benefits (e.g. variables, imports, etc.), which I haven’t even fully explored, but I’m already switching over to SASS for my personal project (Skilldom.org).

So here’s how you set it up:

  • Start with exploring the node-sass package. This seems like the most popular package for SASS in the node world.
  • In your node project folder, simply type:
    npm install node-sass
  • In your app.js (or whatever your main node file is called), add this line right before the “static” configuration:
    app.use(sass.middleware({
    src: __dirname + '/sass',
    dest: __dirname + '/public',
    debug: true,
    outputStyle: 'compressed'
    }));
  • You can, of course, change the paths to point to wherever you want to store the SASS files and the compiled CSS files.
  • That’s it. Now you can reference any CSS file (stored in the /public/stylesheets folder) from any template and node-sass will dynamically compile the corresponding SCSS file (if it exists in the /sass/stylesheets folder) into that CSS file.

So, there you go. It’s that simple!

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!

Getting rid of limiting beliefs

In the last 6 months, I have written about building consistent habits and about building side projects. The truth is, however, that its been hard to live up to all the promises I made to myself. I think that’s why I didn’t start with any major new year resolutions! :) I still need to complete the ones I set out 6 months ago!

I can’t believe I am going to quote Jordan Belfort, but I will because his (or maybe someone else’s) idea of “limiting beliefs” rung true with me when I watched this video. I suggest you watch it too. I then read this post by Tony Robbins about the same topic.

Nothing earth-shattering, but I hadn’t thought too much about the distinction between an idea and a belief, specifically laid out this way. So, with this newfound knowledge, here’s to the new year and to new beliefs.

Bring on 2014!

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.

Short UX review of Quip

So, Quip finally launched their Android app a few days back. I had to try it, so I did. It sort of lost me within the first interaction.

I created a new document, added some dummy content and wanted to share it with a colleague – a specific colleague who wasn’t yet on Quip. Guess what, the share screen didn’t let me send it to him. It seemed like I was limited to just colleagues who have tried Quip with their “work” email addresses.

The share button wouldn't let me share with an email address!
The share button wouldn’t let me share with an email address!

So, there I was, wanting to try the product for what its meant to be – mobile collaboration – and I couldn’t. I was sure I was the one who was mistaken since this is a fairly simple task and they couldn’t possibly have left this feature out.

I was right. Someone at Quip decided to hide the feature of sharing with people who are not in your phone’s contact book in a secondary menu under the “Settings” icon. Yeah. It happened. Well, I hope, for their sake, they fix this soon.

Not the best place to hide a sharing button!
Not the best place to hide a sharing button!

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, Skilldom.org 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.