As most of you know, today is my last day at Recruiterbox.
It has been an incredible experience here; I sincerely feel that working here has made me a better person overall. Joining Rbox is undoubtedly the best decision that I have made so far in my career.
I will really miss you guys.
I wish you all the best for the future, and I hope you guys achieve everything you set your eyes on.
Bye, and thanks for the memories!
For the last month the administering Rbox team has been working hard on api v2 and I felt it is now a good time to share what we have achieved.
Today in Recruiterbox we have the following versions of the api
Some of the problems with the above approach
It is desirable to have a single canonical api for recruiterbox that both our app as well as customers use. This means that you add new features and fix bugs in one place.
Today api v1 has over a hundred endpoints. This is hard to grok for even devs inside Recruiterbox, let only external customers. We need to have a small api surface area and a consistent api, so that is easier for devs to start with and work with. React.js is a very good example of it.
The goal is to totally take out api v1 and have our app use api v2. If an app as complex uses the api, then a lot of our customers can as well. The trick however is to keep the design generic enough and not couple it how our app does certain things. This means we need to have routine discussions on the design of the API.
The admin team has already built a few basic endpoints as a first cut. The idea is that if we build anything new, we should use ApiV2. This isn't as easy as it sounds because you may be enhancing a feature that already has an api, rewriting the api layer can add a lot to your delivery times. This a call that every team needs to take after discussing it with other teams and the admin team. Bigger features like for example the candidate profile page redesign will make sure that we use the new APIs. It has become easier to write and modify the api because of the changes in RIP.
RIP had a few rough edges and issues and it was hard to write resources. The admin team has refactored RIP and fixed the following issues
When we want to present what we are working on -
We typically present a list.
I am working on
Painting the car
Organizing the dashboard
Cleaning the boot
Changing the oil.
We do this is many places.
When asked - Why is your product better? - Out comes, a feature list.
When asked - What is the benefit of a process? - Out comes, a list of benefits.
When asked - How are you solving a problem? - Out comes, a list of items.
When asked - What does your NGO do? - Out comes, a list of activities.
The problem with lists are -
* They are hard to remember
* They are unexciting
* Hard to build on
* Very boring
It does not help that "To do" apps focus on lists.
It does not help that finally we have a bunch of activities to do.
Instead try to build and tell a story.
Stories excite everyone.
Stories are easy to present.
Stories are easy to remember.
"I will be driving my car on a cool trip - Visit places mentioned in this historical novel. So getting my car ready for it."
We have been tuned (evolution) to relate to stories.
"My very educated mother just served us nine pizzas" (or some variation if it).
So when someone asks
"What do .."?
Try starting with
"Once upon a time .."
"Should I put 4 cups rice and 1 cup daal?" - Me
"No. Why do we need so much? We are only 4 people" - Renuka
"But we always use that measurement" - Me
"Come on. We need it for 2 days of Dosa and idlis" - Me
"Oh. I thought you were asking measurements for the Khichdi" - Renuka
"Oh ok" - Me
When we communicate - we make lots of assumptions.
We think what we ask is what the other hears.
We think what we intend is what the other intends.
It is easy to start with wrong assumptions.
It is simple to correct.
Verify your assumptions.
If you are not sure - Ask.
If you are sure - Ask.
If you are really sure - Ask.
A dear friend of mine used to have a saying about assumptions.
It goes something like,
"Assumption is the mother of all fuckups"
"But I guess this time - It is ok. You are not well and It is hard to manage her" - Rajesh
"No" - Renuka
It is easy to explain away the deviation from the principles during difficult circumstances.
"I will skip the code review this time because ..."
"I will respond to customer late because ..."
"I will push my agenda this time because ..."
"I will pay bribe to get this done this time because ..."
"I will test this later at this time because ..."
The "cause" may be genuine.
The deviation may be warranted.
Either you stand for a principle or you do not.
There is no "but this time".
It is OK to decide that you do not agree or stand for a principle.
It is NOT ok to have deviations once you decide to stand for it.
That leads to
above all - "Broken trust"
Below passage was given to me by one of my mentors when I was feeling very down about my volunteer work, where I was receiving a lot of criticism for the work I was doing. He mentioned that 'what you are doing is very rare, try to get more people like this to do' and gave this passage which was spoken by Theodore Roosevelt. Nelson Mandela was also inspired by this and gave it to his national sports teams.
It is not the critic who counts;
not the person who points out how the strong person stumbles,
or where the doer of deeds could have done them better.
The credit belongs to the person who is actually in the arena,
whose face is marred by dust and sweat and blood;
who strives valiantly; who errs,
who comes short again and again,
because there is no effort without error and shortcoming;
but who does actually strive to do the deeds;
who knows great enthusiasms, the great devotions;
who spend themselves in a worthy cause;
who at the best knows in the end the triumph of high achievement,
and who at the worst,
if they fail, at least fail while daring greatly,
so that their place shall never be with those cold and timid souls who neither know victory nor defeat.
"Why do you go to work, why not mama"? Titli
"Some answer .."
"For a restaurant it is good if they turn tables fast in a evening" - Rajesh
"What is 'turning tables'" - Girish
"Why is it good?" - Girish
"Is it true for all restaurants?" - Girish
Here lies the answer for the "Creator's curse".
When a question is asked about a thing that we have created mostly we do NOT hear the question being asked.
We hear it as "blah blah? You have not considered it? I just found that gap. What the heck you were thinking?"
or some variation of it.
If you have an inherent curious nature - You will probe more.
You will ask questions to understand more.
You will try to understand.
But that is hard.
Our instinct plays it part esp. when we are presenting to audience.
It make us defensive.
So here is a simple trick.
Always have a note book and pen when you are presenting.
When someone asks a question - Write it down.
(This helps to increase your response time. It cuts your instinct to add unnecessary addition to the actual question being asked. It helps to get clarity about the question. )
If you are not able to note it down clearly ask only questions that help you to note it down well.
Repeat the noted question to the person who asked it.
Thank the person.
Follow up later (if that is possible else respond now).
I am going to call it "Child like curiosity". (for obvious reasons)
Either have it.
or fake it.
It is a perfect Anti- Dote.
A recent post about - 'how wrong our instincts can be!' triggered some thought process.
I always wondered -
If eating healthy food is good, why do we get attracted (most of us) to sugar and fatty foods?
If exercising is good, why we have to discipline ourselves to do it regularly?
If learning is good, why do we have heated arguments with others who have different point of views?
If evolution works the way we think it does then, given the above - Why is our gut/instinctual reaction wrong?
We should be enjoying eating healthy food.
We should be exercising for pleasure.
We would be naturally curious.
Then a realization stuck me.
Our current level of abundance (in terms of food), freedom ( in terms of time), interaction action (with others) are a very recent phenomenon. Probably the last 100 years have changed these so much that our instincts that developed over millennia is yet to adapt to it.
Instinct for eating foods high on sugar and fat developed when they were scarce and body wants to consume and hoard as much as possible.
Instinct of intense physical activity is primarily oriented towards getting food. it is primed to NOT perform other activities. You have to be physically fit and able to use your body to hunt else you go hungry.
Instinct of defense developed to survive "Death by curiosity" or "Dissidence".
Our instincts are highly developed and good.
Just that it is a like "Gladiator" surviving in the modern civilization.
They do not fit in with the existing environment.
We have to control our instincts and work to get it right in the new environment.
That is why,
It is hard.
This thoughts reminded me of Robot_AL-76_Goes_Astray - A fascinating (little) story of a lost robot who was designed for working in the moon but lands in rural Virginia. Check it out if you are a fan of Asimov in the "The Rest of the Robots"
"Have you considered this scenario while ... ?" - X
"Do you think that is how a person will think ...?" - Y
"This seems to be confusing when I click ...?" - Z
It is surprising how quick the inputs flow through from people who are looking at anything you built (UI/UX, Product, Code, Business plan, Startup idea ...) for the first time.
Our first reaction is
"I have spent hours thinking about it. I have a good reason why the thing I built is like this. Do you think I am stupid. Here is the explanation for ...."
We are cursed to be blind - Being the creator of the thing, we are very deeply aligned with what has been created. We become blind to its short comings.
A simple test:
When someone presents you the outcome of their work - count the number of gaps/challenges you see in the output, without thinking a lot.
Take any of your finished work - see if you can match or beat the above number in the same amount of time.
You will know if you are cursed.
There is a simple and effective way to workaround this (not sure if it can be avoided) - In the next post.
There seems to be another definition already for Creator's curse. But I could not come up with a better name for the phenomenon I described.
"Are you not bathing today?" - Renuka
I get irritated.
"Why are you not asking 'When are you not bathing today?'?" - I retort (with a raised voice).
"That's what I asked" - Renuka
When I hear the question, there is a narration in my head.
It is based on my background (combination of ethnic, cultural, beliefs).
I was brought up as an equivalent of a "TamBhram - Iyer".
Only "brushing teeth" was allowed without bathing.
Bathing is the first (may be 3rd if counted accurately) thing we do in a day.
So what I hear when the question is asked as
"Are you not bathing today?"
"It is way past bathing time. You have not shown any inclination to take bath and are performing activities that should not be performed without bathing. Are you going to continue with this?"
We think what we ask is what the other person hears.
Not necessarily true.
We all have a narration in our head that interprets what's being said.
What you ask is "Have you considered simplifying the options, this seems complex?". What the other hears is "You seemed to have come up with a complex option. Why can't you come up with a simple one?"
What you ask is "Do you need help to have clarity on what and how you are going to do things?". What the other hears is "Hey! I think things are not being planned well. I want to know what and how you are planning to do things."
* When asking - be sensitive to the narration in the other persons head. If it triggers behaviour you do not expect probably what you asked is not what he hears.
* When responding - clarify the story in your head. What you hear is not probably what the other person asked.
It will make work and personal life simple.
"Interface" is an interesting concept of Object Oriented Programming.
I am fascinated by the 2 (the ones that I like most) important tenets of an interface:
* Interface exposes the behaviour i.e. what is expected out of the function call if you pass the defined parameters? It does not expose the implementation. In Fact it is designed to abstract the implementation. It is a contract with the external world.
* Interface enforces the implementer to think through contract of the exposed functions and handle them well. It ensures that whoever implements it, need not reinvent the contract everytime. Removes the communication overhead that comes with change of contracts.
As Recruiterbox is growing and more people have started contributing at various levels, the 2 tenets are helping me to think about how I can work well with them.
* I am treating each function (engineering, ops, product, design, marketing, sales) as an interface. I know exactly what every function is expected to do - "Defined by outcomes". But I do not have to worry about how it is done (curiosity may still exist).
* Within each function, the team understands the promised outcome and designs ways of achieving the outcomes. There is a conscious evaluation of the contract and implementation that works well for that team's current strength. This is defined by the "Rituals" (I prefer this term over process - details in another post) followed by the function.
Reference : What is Interface? - http://stackoverflow.com/questions/3355408/explaining-interfaces-to-students
While visiting other countries I noticed that many of these countries had some form of citizen duty. There was jury duty, military duty, even precise waste segregation and proper disposal is a duty. Before leaving out of India I have not heard about this, where citizens are supposed to do their part. I feel we are the most pampered citizens in this world. In these countries it was not just limited to country duty, people were signing up for a lot of things which I usually have not observed at home. At one of the startups I was having an assignment, the CEO and his family dusted and mopped the company in the weekends while I was leaving my used cups on the table. This visit changed me, I made it a point to never litter even though there is someone employed to clean it up later.
Recruiterbox is unique, it was very evident for the office move. Apart from the core team there were many who reached out asking how can they help. There were a lot of people helping over the weekend with whatever task they can do including cleaning the desks, fixing network, buying food for others, running errands all in the middle of that dust, paint smell and long hours of standing. I have been part of office moves in other places, people usually wait for someone else to ask volunteers. Most of the office moves, people just stepped out of the old office and the next working day came down to the new one unlike us. This is what will make us stand out when we go behind our business goals as well.
When I chose my specialization in undergrad (Engineering) - The following was my thought process:
"Mechanical engineering is an evolved subject. Everything has a reference book (strength of materials, ratios to be followed for design etc).
Computer science is still evolving. New languages come every 2 years - Java had just been out. How long you will have to keep learning new things?
So - Mechanical it is."
Life laughs with ironies.
Though relatively young, it is amazing to see the number of paradigms that are evolving in computing science.
One that has created profound influence is - The free and open source software.
Professionals (who are really accomplished) - write free code for others to use.
From small libraries to operating systems there are tons of free (with source) stuff available.
Newbies can learn from it.
Good ones can contribute to it.
Others can use it.
As a amateur in some fields - Food production, Earth based construction, Design - I find the lack of equivalent of "free open source content" are not present.
Does this reflect on the professionals?
or the profession?
Abstraction and compression are used interchangeably. What is the difference?
In a restaurant setting the restaurant manager or waiter has to deal with abstractions on how a food is cooked, presented to the customer. All they need to know is how long dishes take to make, how much does it cost and is it doable on that particular day. The kitchen is a black box for these people, they place the order and expect an output, some times even if it is doable or not. It is not that the manager and waiter are not capable of understanding what is going on inside the kitchen, it is just not judicious of their mind space.
Inside the kitchen abstractions are not productive. Each person needs to know what the other person is doing and they will use compressed language. For example, lime juice marination means the exact same way the marinade is prepared as the chef intended and the cook does exactly that. If there is a change they discuss the details. It is the process and the outcome together.
In software development business works with the engineers in abstract terms. It is a black box for them. Engineers work within themselves using compressed terms, each one knows the exact steps that will be taken by the others. From the outside both looks like abstraction, it is not.
"We should always heat the older packet before opening the new one" - Renuka
"Yes I agree. The way to do it is, by ensuring the oldest packet is in the front. We have to ensure that" - Me
"But why don't you check the dates before heating the milk? It is possible that we may forget to put it in the front"
"How can we forget if we agree that is what we will do? It is waste of time and mindspace (hmm Rbox effect), if I have to check it every time. It is a very simple rule to follow"
"But it can ..."
"No. I Guess then you are ..."
We DID agree on the intended outcome.
What we did NOT agree about was "How to get it?".
It happens a lot.
As long as we agree on the outcomes, leave the "How?" to the person who manages it.
Discussing 'how' leads to discussing unintended 'whats', 'whys' and 'hows'.
If you feel strongly about the "How?" then may be you should own it or talk about it later.
* We buy unpasteurized organic milk. It has a shelf life (in refrigerator) of 2 days. The supply can be erratic and so we maintain one day inventory. This milk has to be be heated (boiled) before consumption.
* Being the early riser, I put the milk packets in the refrigerator - Oldest in the front and the last in the back. When I heat the milk, I just pick up the front most packets. When Renuka heats the milk, she checks the dates :-).
We finally moved to React v15 today. These are something that went well, and what are the loose ends that we need to tie up before the next update.
Choosing a third party library
We need to get better at picking UI libraries. For instance react-bootstrap doesn't follow any standards, and has breaking changes for every minor bump. They say this in their homepage and still we picked it. For some reason we're ok with sticking with existing solutions even when they clearly don't suit our needs. The time we spent on hacking react-select(still not merged, even after a year - https://github.com/JedWatson/react-select/pull/660 :P) we could've built one.
Not running multiple versions of React/ Locking library versions
Ideally we should've done the upgrade before introducing libraries that were dependent on React 15. We're not enforcing this, and this leads to a lot of script errors. Check this (https://github.com/facebook/react/issues/1939) for some context. Looks like the solution is to lock the dependencies and have npm/yarn scream at us when we add a library that doesn't comply with the package requirements.
React select covers a lot of scenarios, but it breaks for a lot of our UI requirements
Plus the library is very slow in accepting PR's. We may have to start looking out for another library, or better yet, write one ourselves and open source it :D
SortableJS is unmaintained for quite some time and is using a lot of non standard code. Someone has written a wrapper over it(https://github.com/cheton/react-sortable/) and seems to be popular. We need to evaluate it and close it before the next major react upgrade.
react-bootstrap is a non standard library and very slow moving. They moved from 0.27 to 0.30 in the last year and a half, with so many breaking changes. They don't seem to have a clear path for a stable release.
We need to evaluate other options like blueprint.js or build our standard components soon. This will hit us in the next react upgrade.
People say when you are part of a system you don't observe the changes it brings it in you and how the system itself changes, unless you are good at taking frequent stops and reflecting or someone else from outside making that observation.
I found an addictive game to play called circle the cat which I used to play whenever I got a chance. This was so disruptive that I was waiting for build to happen for my commits to play this game. When I joined the project, the build used to take only 2 minutes, but over the course of few months it steadily climbed to be 12 minutes. My commits became complex because I had to wait longer for every commit but I was enjoying the break to play a game.
One such day when I was waiting for the 12 minute build to get over, my tech lead who came out of a tiring tech discussion watched me playing this game and I could see he was very angry. I enquired how he is doing, was the discussion tough. Instead he said that he was angry on me that I was playing using build time as an excuse instead of trying to fix the slow build.
He was right, I never realised that I was sitting on a problem which could have been solved and made me and my team much more productive. It did not matter how others were thinking, I was thinking I was doing a good job and pushing code as much as possible. If he had not pointed out, I would have never attempted to fix. I tried to find the root cause and I ended up reducing the build time to under 2 minutes within the time I took to play one game.
Back in 2011, the early days of Recruiterbox, I used to split my time between marketing, sales demos and customer support. Even back then, most of the inbound traffic was from the US and I used to stay up till 3 am replying to support tickets within 2-3 mins of them coming in. While I slept, Girish used to wake up at 5 am and take over support till I woke up in the morning. Between Girish and me, and sometimes Raghu too, who was our only fullstack developer, we used to cover support tickets 24/7.
We did not know what the best practice here was - maybe it was 4 hours or one business day. But we just wanted it to be instant. Personally, I was uncomfortable with anyone waiting because it would annoy me if I was in their shoes. And Girish always said "we may not have all the features and a big product, but what we have is the power to provide instant gratification." The customer would feel like we are sitting right there in front of them and their requests are not going into a black hole.
Within the realm of tickets, my pet peeves were bugs. Especially, front end ones that might stop the customer from doing their work. Not being an engineer myself, it used to give me almost a panic attack if there was a front end bug on the system. I used to either wake Girish up, who was my roomate at the time and slept in the next room, and ask him if he could fix it right away. Or in the office, I would stand over Raghu while he tried his best to fix things that were coming in. It took me a while to understand that bugs were a normal part of the development process, and they were a cost we had to pay to deploy things quickly. Raghu spent months trying to explain to me that some bugs would always occur and they were just two developers coding 12-14 hours per day. He lost most of his hair trying to keep the product going in those early days, while explaining basics to me. (p.s. will always be thankful to them for the quasi engineering education I received in the first two years).
I am extremely happy that we managed to not only preserve that value in our company, but it is thriving under this new army of super passionate happiness folks. Values make us who we are uniquely, where as best practices are something every company can do or ought to do. What we have to be careful of is we don't use some publicly derived best practices as our best work. An excuse to do the least. Or an excuse to believe that this is the best we can do with what we have.
Other than instant and immense customer empathy, I would love to know what values you guys think our company ought to have? Number one on my list is a sense of urgency. I think we can get much better at that in many of our teams.
Thanks for reading!
Too many choices exhaust us, make us unhappy and result sometimes in not making a decision all together. Decision paralysis is one of the major factor for procrastination and stress.
Even if we chose one, we are mostly less satisfied for one of the below reasons.
Due to this constant comparison of choices, our expectations goes up leaving us less satisfied with our lives.
Researcher Barry Schwartz in his book “The Paradox of choice” mentions “As the number of options increases, the costs, in time and effort, of gathering the information needed to make a good choice also increase. The level of certainty people have about their choice decreases. And the anticipation that they will regret their choice increases.
With more options to choose from, we become mentally tired and the principle of least effort kicks in where we make the decision based on the easiest option/factor available.
Learning to Not Feel Guilty
About 2 weeks ago I started feeling something weird in my hand and mentioned it to my Happiness Team, just during a casual conversation. They urged me to see a doctor ASAP and to take time off if I could get an appointment.
But I didn't. _Because I felt guilty having just taken 2 vacation days off earlier in the month. _So instead, I went to an Urgent Care Center after work hours.
Over this past weekend, I ended up back in Urgent Care where the doctor told me to take a day off work and prescribed some pain medication.
I thought to myself, "How can I avoid actually taking time a day off? Maybe I can just handle tickets, but not chat since I'd have to type very slow..."
But WHY was this even a question I asked myself? Why did I feel this way? I wasn't going to be very useful at work with a bum arm. Why couldn't I just let myself rest?
At Recruiterbox, I have a team that has my back, cares about me, and realizes that I'm not a robot. I will get sick. I will need vacations. I will have last-minute emergencies. I've never shown signs of taking advantage of my team, so where does the fear that they think that I would come from?
Monday was a big stepping stone for me in learning to not feel guilty about caring about myself as much as others do. I still need to keep working at it, but I'll get there thanks to my team :)