Parathought

Every startup goes through phases of limbo. Often, when a dev founder finds herself in this situation, she tries to squeeze out of it by more programming. Writing code gives us programmers a sense of doing something (even though it may not be useful). 

I'm making myself a framework to combat this. It involves the following steps:

1. Start with a hypothesis. Something like "People will use this for X", or "People will prefer this instead of Y" etc. Define who "people" are. Define the test. What will tell me that the hypothesis is true? A good hypothesis is narrow (regarding its audience as well as what's being tested ). Coming up with a testable hypothesis is the most important step. 
2. Decide what needs to be built to test this hypothesis. Chuck everything that does not do this - it's extraneous. Estimate time required to build this
3. Build it. In more or less the estimated time. 
4. Run the test. This usually means showing it to some users. Become better at interviewing users. Focus on questions that test the hypothesis

At the end of every such cycle, articulate what you learnt. Repeat. 

It's becoming increasingly important that we write. Not only does it help us redefine our thoughts, the internet makes it the most potent form of expression.

Yet, most of us don't (myself included). 

So, what stops us from writing? A few candidates:

• I don't know what to write about
• Who'd read this anyway?
• This sounds stupid. Is this worthy of being written?

I know there are philosophical rebuttals to each of the above points. For instance: "You should write for your own sake and not for an audience." However, I'm not convinced that the answer lies there. I wonder if the tools we use for writing can help us overcome these.

A few weeks ago, we met Shekhar Kirani from Accel. Shekhar has been a friend to Aplopio/Recruiterbox, and we often discuss about the hiring space. I was particularly excited about the ideas he mentioned this time.

• Employers need to write better job descriptions. Ones that truly represent what a potential employee would experience if and when he/she joins. Most JDs are just drab, dry, characterless prose. Is there a way to improve this?
• Today, most inbound recruiting efforts involve employee referrals and recruiters. What if we could extend the employee referrals to look like recruiters. Imagine a network of people (say, devs) who have other good professionals (other devs) in their network, and refer these professionals for a fee. They are better than recruiters because these guys are devs themselves, and consequently better at identifying other good devs. Some people are just good at identifying and curating talent.

We are hiring at Aplopio, and one of common points of debate is deciding the compensation for a potential hire. For this, we are trying to come up with a system where we decide the "level" of a person. The level determines the range of compensation. There are a couple of axioms that we follow:

• The levels apply to existing as well as potential employees
• The compensation range for a given level depends on the specialization (for example, level 2 marketing person can have a different compensation range than a level 2 front-end engineer)

Levels can make the compensation discussion more objective. But note that we have merely deferred the discussion from compensation to competence, and unless we can objectively describe competence, we haven't achieved anything. 

My personal belief is that competence is better described through the work of a person rather than the person himself/herself. This seems simplistic and trivial, but is crucial. Work can be measured better than people attributes. From a developer standpoint, modular code, maintainable code, test driven code, optimized code etc are attributes of a program (and not the programmer). I don't have the answers to do this universally (and well) yet, but I feel this is the direction to go. 

Another case in point is when you consider remote workers. How can you evaluate a person you've never met? You'd rather evaluate their work, isn't it?

I came across this excellent talk: http://www.confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-years . Ironically, the best way to write web-apps is to not write web-apps. I mean, we should just write applications. Without assuming anything about the web, http etc. Http is a just a delivery mechanism, a detail. The app should work as a library or a gem. Apparently, the app needn't even be closely integrated with the datastore. This is the part that Raghu and I are debating. Should a web-app assume a datastore? Should it implement the datastore? 

We were chatting with Prateek Dayal and Avinasha from SupportBee yesterday about strategies for hiring. Takeaway: Pitch the work environment. Tell them how unique your internal processes are. Tell them why working with you will make them awesome. Help employees showcase their work

I was speaking with Avinash of SupportBee today. He shared an interesting way of looking at webapps. What if we looked at webapps as one blob that holds all the business-logic, interfaced with a persistent store (db) and a http web-interface. This isn't MVC, where the business logic gets invariably sprinkled over models, views and controllers. "Think of it like as writing normal ruby/python object oriented code, that simply plugs into a storage and http providing interface". This needs in-memory model-like objects (apparently, Active Model in Rails does this) without the saving part, and some lightweight http interface (flask?).

What if there was a facemash for devs? A place where you compare two dev resumes side-by-side, and pick the better one. Title is "Which dev would you hire?". Or tinderapp thing where a dev is shown and you decide "Whether he/she is good?"