Image
Hey there! Check out how we work at recruiterbox
or  Ask us anything
Ask Us
Ask: I'm happy with my current work. Why should I consider working with Recruiterbox?
Ask: What is a normal day @Recruiterbox look like?

Recent

Adios!

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!

Edit Permalink

Api v2 and the way forward

Folks,

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.

###

Why another version of the api ?

Today in Recruiterbox we have the following versions of the api

  1. v1 (eg. /api/v1/openings ) it is a mix of Tasty pie endpoints and some RIP
  2. public_api/v1 (eg. /public_api/v1/openings ) written in RIP authenticated using an api token
  3. js api ( eg. js_api/v1/openings) written in RIP and unauthenticated because it is supposed to be used for customers' career pages.

Some of the problems with the above approach

  • The same entity has multiple endpoints and different conventions of schema which means when we add a new feature or fix bugs we need to do it in multiple places
  • Some of the design decisions are not consistent with each other and not very popular in the external world eg. sub resources, some resources modelled as CRUD endpoints and some others as commands and View.

There is no public and private

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.

Small API surface

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.

Dogfooding is the best way to VALIDATE THE API's DESIGN

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.

All that is awesome, but where are we right now ?

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.

API Endpoints are now easier to write with 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

  • There are sensible defaults for error messages (there were null responses before)
  • All the logic of a resource resides in one class and by extension one place/file Developers have to extend the CrudResource and all the authentication, authorization, entity actions, serialization hooks etc are on the same class. All exsiting resources have been moved to the new style, so no two ways of doing things.
  • Flattened hierarchy in the RIP codebase means if you want to know how CrudResource works, then it is just about reading the code in one class, most classes don't inherit from anything. This is a decent substitute for documentation until we get there.
  • There is a base class for all apiv2 resources called CrudResourceV2, a lot of common logic like authorization which is common across all api endpoints can go here. Developers don't need to add code or tests for this common logic.
Edit Permalink

Once upon a time ...

When we want to present what we are working on -

We typically present a list.

I am working on

  1. Painting the car

  2. Organizing the dashboard

  3. Cleaning the boot

  4. 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.

Remember

"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 .."


PS :

  1. "Made to Stick" is a wonderful book that talks about messages that stick. Stories are a repeated them that come in that.

  2. "Start with why" is another book that talks about conveying "Why?" being the core. "What?" and "How?" follow them.

Edit Permalink

Assumption is ...

"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

"No"

"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"

Edit Permalink

"But this time" - Is a dangerous spiral

"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.

But

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

  • Inconsistency

  • Illusion

  • Lie

above all - "Broken trust"

Edit Permalink

Citizen duty - Be the person in the arena than being a critic

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.

Edit Permalink

Creator's Curse - The Cure

"Why do you go to work, why not mama"? Titli

"some answer"

"Why?" Titli

"Some answer .."

"Why?" Titli


"For a restaurant it is good if they turn tables fast in a evening" - Rajesh

"What is 'turning tables'" - Girish

"Some answer"

"Why is it good?" - Girish

"Some answer"

"Is it true for all restaurants?" - Girish

"Some answer"


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.

Edit Permalink

Instincts - Built Right but is in the wrong place

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.

PS:

  1. Ref: http://alearningaday.com/2016/11/instincts-suck-first/

  2. 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"

Edit Permalink

Creator's Curse

"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.

I am.


There is a simple and effective way to workaround this (not sure if it can be avoided) - In the next post.

PS:

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.

Edit Permalink

What is you ask is not what the other hears!

"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?"

is

"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?"


Happens everywhere.

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."

Two takeaways:

* 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.

Edit Permalink

Interfaces - How it helps manage expectations at work?

"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.

PS:

Reference : What is Interface? - http://stackoverflow.com/questions/3355408/explaining-interfaces-to-students

Edit Permalink

Citizen Duty

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.

Edit Permalink

Free and Open source - Why only Software?

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?

Edit Permalink

Abstraction vs Compression

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.

Edit Permalink

Intended Outcomes

"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.

At home.

At work.

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.

PS:

* 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 :-).

Edit Permalink

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.

What went well

  • Removing dependencies one by one instead of a big bang change
  • Changes had a small area of impact
  • Faster testing.

What could have gone better

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.

Loose ends, and what next

Throw react-select

React select covers a lot of scenarios, but it breaks for a lot of our UI requirements

  • creating new option
  • extending the menu renderer and so on

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

Sortable js

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

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.

Other minor changes

  • We're moving to yarn. Yarn is much faster when compared to npm and warns us when a library is outdated or is incompatible with other dependencies
  • enzyme is in for writing component tests. Even facebook's document recommends it. We need to slowly move all skindeep tests to enzyme and remove that as a dependency
  • the current version of hot-reloader is incompatible with react v15. So I've removed it for now.
  • React is now more particular about the props that we pass. We can no longer pass a random argument to our component. For instance <input minWidth="100"/> will throw a warning. For more information read https://fb.me/react-unknown-prop.
Edit Permalink

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.

Edit Permalink

Values vs Best practices

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!

Edit Permalink

More is less ???

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.

  1. If the chosen option isn’t what we expected, we keep regretting our decision.
  2. We evaluate the chosen option with the other missed options resulting in unhappiness with our choice.
  3. 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.

Published at https://medium.com/@hanu/https-medium-com-hanu-why-more-is-less-fed8e573050d#.vd98z528d

Edit Permalink

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 :)

Edit Permalink