A Tale of Curiosity at work - work doesn't have to be boring
Tags: beginners, ruby
Published: 2019-06-01 06:45:00

Well my usual articles are dead boring so today I'm going to switch it up a bit. Today I'm going to talk about, a day at work. Or if you will, *A Tale of Curiosity*. I promise it'll be fun, or at least I'll try to make it so.

![img](https://media.giphy.com/media/3KCOFfdqmptLi/giphy.gif)

Recently my team and I have been integrating with a third-party API, and I was tasked to translate the error returned by the third-party API into something that we can show to our user.

For example, if the third-party API responds with:

```ruby
{
  "code": "123",
  "message": "Error message from third-party"
}
```

We do not necessarily want to render their message to our users, because it could very well be some random error that user would not understand (e.g `Required argument is not passed in`), also the fact that by mapping their error codes to our own allows us to control the tone and voice of our company. So, time to work!

After a bit, I was done with my task and I sent it off to a co-worker for review, like hooray, time for the next task.

He came back to me in 5 minutes and asked: ***why did you do it this way***?

The pull request in question looks like this:

![](https://thepracticaldev.s3.amazonaws.com/i/jum31cohz2djhixg6798.png)

In fact, he was specifically asking me why did I choose to memoize my `error_hash` method?

The conversation went like this:

> C: Hey why did you memoize this hash?
> Me: Well, we're going to be accessing this rather often, wouldn't want to recalculate it again and again since this value is not going to change.
> C: But you only really memoize for expensive computation, such as database calls, API calls etc.
> Me: That makes sense, but I want every single call to `error_hash` to return me the same object, so it's more memory efficient that way.
> C: I don't really see that as a good reason. And is that really how it works?
> Me: Honestly I'm not quite sure, I just sort of assumed that. Can I get like 10 minutes to run a benchmark to figure it out?
> C: You bet.

So I decided to do a quick benchmark to see if my hypothesis was right (and because I'm going to prove that little sucker wrong): that memoizing will return me the exact same object in memory, while if I don't, a new Hash gets generated every time.

Since this is a case of interacting with the Ruby memory, I turned to my best friend `ObjectSpace` (whom I've mentioned in a couple of my article). `ObjectSpace` basically allows you to interact with the living objects at runtime. Perfect fit for us!

I took about 10 mins to whip up [this quick script](https://gist.github.com/edisonywh/32ddf65865cc1c91eeedfa929a2d0bec). You can take a look at the code if you'd wish, but basically what I had hypothesized was accurate, that if I don't memoize it'd generate a lot of extra objects in memory.

However, did I go with my approach? Nope. He then asked me why didn't I just used a constant, and I realized that's exactly what I wanted, so I've updated my solution to use a constant instead.

## Takeaways

Well if there's one thing that I hope you can take away from this is that you should **be open to learning/feedback**.

Let's take a look at this:

- My colleague has questioned me, not in the tone of superiority, but genuine **curiosity** as to why I did what I did.
- I explained why I did and he did not really agree with it, but we decided that I can run some tests to back up my claim.
- I did exactly that, and now we have more data to be used in our judgement.
- We both assessed the new information and decided that there's a better way (constant), and we both chose to let down our previously held opinion and go with what's the best solution.

This little interaction took maybe about tops of 15 minutes? And within 15 minutes we were able to learn more about Ruby internals and go home with more knowledge.

What looked like a mundane task at first had just turned into an interesting learning session, and it only happened because we were both curious. **Trust me, curiosity doesn't kill the cat, let loose and let your curiosity roam free!**

I hope by reading this, I had encouraged you to hold the mind of a curious and ask yourself, is there something I can learn from this, no matter how mundane the task looks.

**If you have any similar story where you managed to turn a mundane task into a great learning opportunity, feel free to share them down in the comments!**

Right, better head back to work now before my manager taps on my shoulder. (*well he doesn't really do that*..)