How to appear to have high energy all the time

I’m inspired by how driven some people can be. It’s not everyday that you get genuinely impressed by someone’s energy, particularly not through social media. But I did today and after the inspiration surged through my veins, I find myself just sitting here and wondering two things. Why the hell am I sitting here watching people do stuff? What will I do if I had that kind of energy?

Let’s get one big thing out of the way first. “That kind of energy” is not something some lucky or special people are born with. No, I don’t buy that. It’s obviously nurtured. I know this because I’ve felt incredibly motivated before, and chances are, you have too. It depends on what you’re doing. I think we just need to do something we’re decently good at and find meaningful. That’s the trick to getting “that kind of energy”.

Well, at least part of the trick. There’s an important part that is less examined, I think, and that’s our natural tendencies.

I naturally tend towards being in quiet places. Without supervision, I also tend to be lazy. If I had the lovely evening after work to myself, I tend to not create but consume. And even though I recognise that this is inhibiting my growth as a professional and as a person as a whole, I just tend to be lazy, you know?

Now here’s a non-revelation: a tendency to (not) do something is a phenomenon, a manifestation of some underlying idea. I think the idea that underlines my tendency to consume instead of create (ie. being lazy) is that there’s no need to work so hard all the time, every time.

After a long day’s work where I’m not lazy (it’s a professional environment), why get home and do more stuff? Productivity is a business idea. Sounds fair enough, right?

What I haven’t realised before is that the way I think about after-work work is wrong. Calling it after-work work is already a fallacy. While not working hard all the time is something I still agree with as a general principle in life, the things we do during time we have after work and on weekends (minus that which is spent with family) are not work. They should not be called work.

The things we do in our free time are expressions.

Expressions of our expertise gained from working hard at our day jobs.

Expressions of our creativity, pent up and brewing from every walk around the block, every moment of politicking, every pocket of thinking unmolested by distractions.

Expressions of our identity, as a “writer” or “programmer” or “some other label”.

Expressions of us. Me. You.

Witnessing this stranger’s expressions on social media today helped me come to this epiphany. On the surface, it looks like this person has unbelievable energy. Something unique, something unattainable. Born with.

But as I dug deeper, I felt more uncomfortable. What’s the secret? Why is she doing all that and I’m here doing all… this? Sitting here YouTube video-hopping. All this while knowing in my heart that I really want to read a book, write something or strum my ukulele.

I think that was when it hit me. As much as I do, this person I stumbled upon from watching one too many videos on YouTube probably doesn’t see herself as working hard. That’s me seeing the world through my lens. Through her lens, she’s just making good use of her time expressing herself!

To put this new idea to the test, I sat here, in my swivel chair at home staring at my monitor with my dog Brownie lying on the floor next to me. I told myself this isn’t work. I am not working. Whatever I do now is extra, it’s unaccounted for. Whatever I choose to do now is just an expression. So… what will I do?

It took five minutes for my mind to accept that this idea might have a kernel of truth, but when I did, I suddenly felt the urge to write. What I wrote is what I’m writing now.

(This is by no means justification for always writing only when you’re inspired, nor is it an excuse to write unfiltered, stream of consciousness essays all the time. Too much of either lands any writer in a world with few and mostly unenjoyable essays.)

So… what’s the TLDR?

  • Stuff we do in our free time should never be seen as “work”
  • The notion of “working hard all the time” confuses us into thinking that if we do anything productive in our free time, we must be working too hard
  • What we do in our free time are expressions
  • When you express yourself, you appear to have high energy
  • When you appear to have high energy, you actually have high energy
  • When you have high energy, you’re happier and express yourself more

Ultimately, for maximum happiness, focus on expressing, not consuming or even “creating”. Now I get why the prolific reader-writer Maria Popova says “there’s nothing more toxic than calling your writing content”. Just express, don’t create and measure it!

The better way to approach a new programming language at work

Since joining the Metisa team at Altitude Labs, I’ve had to learn a new programming language: Python. Before this I’d only known JavaScript and Ruby. When I learned that I’d be joining as a software engineer, I started doing coding challenges on Codewars. Was that enough? Nope. A software engineer at a startup needs to know much more than how to write clean and efficient algorithms!

The challenges of coding in Python were not unexpected, but I was surprised at the way I unknowingly dealt with it. Let me explain.

On a day to day basis at work (on the programming front), I have to:

  • Understand new sections of the existing Python codebase (consisting of 300k+ lines of code)
  • Modify parts of the code
  • Write code for new features
  • Ensure that the above continues to work with the rest of the codebase (ie. not introducing bugs)

There are at least 2 distinct ways to approach these tasks:

  1. Mimic what has been done by the engineers who wrote the existing code
  2. Learn the fundamentals of the Python language and the web framework Django, and write code informed by that understanding

For reasons unapparent until now, I’d been approaching my tasks the first way. That is, I constantly looked within the project that already did what I’m supposed to do or something similar, take “inspiration” by copying the code and modifying it based on what other engineers in the team had done.

This felt so natural that I never stopped to question it.

Approach 1: Mimicking existing code

Benefits of mimicry

First of all, let’s be clear. Before an engineer ever chooses to mimic the existing codebase, he must first trust it.

Python code looks very similar to Ruby on the surface (though it has significant differences I won’t dive into) and because I knew Ruby, I could roughly make out what different parts of the project were responsible

After reading through the codebase the first time, I got a sense that the project was not haphazardly stitched together by engineers who didn’t communicate with one another. The code is DRY (do not repeat yourself) and modular, and most of the files were placed in directories that felt natural. All was good.

As a junior engineer, you tend to think that any other engineer is better than you. Thankfully for me, this is the truth at Metisa. I’m working with terrific engineers.

Once I’ve learned to trust that my predecessors have done a good job building the project, I naturally assumed that the way they had approached problem-solving in their code must have been well thought-out. A lot of it even looks like they had been refactored (ie. reorganised and made more succinct and readable).

If that’s the case, why should I bother to reinvent the wheel? It made more sense to ride on the shoulders of my fellow engineers.

I think I subconsciously reasoned it like this:

  • an engineer (who is better than me) wrote all this code
  • based on what I can understand of the codebase, most of the code looks well-written
  • if the above is true, then it’s probably right to assume that every design pattern, every decision has been thought through
  • therefore it would be a waste of my time trying to construct what has already been constructed
  • /copies, pastes, modifies

I still think the above is logical. Ok, perhaps the assumption that everything is well thought through just because most of it are is bordering on fallacious. But the rest of it makes sense and are mostly true based on my experience so far.

But there’s one thing I haven’t mentioned yet that is a major force behind everything we do at a startup like Metisa. That’s time. I believed that by copying and pasting and modifying, I’d be moving faster. The faster I move, the quicker my team and I can ship changes and features, and ultimately, the sooner we can reach more customers.

But it’s become apparent to me recently that mimicking code is slowing things down instead of speeding them up.

Problems with mimicry

I realised this problem by chance. Recently as I was working on revamping the Weekly Report that we send out to our users about the health of their e-commerce business, what I thought would be a single-day job turned out to take 3 days.

When these things happen, you just have to get to the bottom of it. I took a hard look at what went wrong, at what made the process so much longer than I’d anticipated, and I chalk it up to my mimicry.

Because I had been mimicking existing code, when I was presented a problem that required fresh thinking, I struggled to come up with a solution.

I struggled to find something in the codebase to lift and rework. That struggle cost me almost 2 extra days. I’d opened every file and done global searches within the codebase with no result. Then, when I felt like I’d exhausted this method, I looked outside of the project for the first time.

Boy was it a cathartic moment.

Approach 2: Coding from understanding

Django (the Python web framework we used) has great documentation. It’s full of examples and it reads like a personal tutor’s notes. When I finally referred to it I found myself saying to myself, “what have I been doing this whole time?”

Here’s the embarrassing thing: I was taught to read documentation while learning to be a developer at General Assembly. We were told that the source of truth is the documentation of whatever library/framework you are using, so refer to it accordingly.

But I think I must have reasoned in my head that reading documentation is quite time consuming, and I couldn’t afford the time.Compared to mimicking code, it felt slower. (Also, if you code like the engineers around you, they are more likely to appreciate and like your work when you submit your pull request…)

But the truth that I now see is that learning how things work, especially things like the frameworks and tools you use on a daily basis as a software engineer, is going to save you time in the long run. Now that I understand that Django queries start with Tablename.objects and have a list of methods that are chainable like .filter(action=‘click’) and you can sum certain values up with annotations, and so on, I know exactly what to do next time I need to query the database.

The point is this: the more you try to understand the code, the greater the number of cases/problems you are ready to code for. I think this observation has something in common with the other one I made about always starting with the basics.


Sort-of-understanding code and mimicking other people’s code may save you time in the short run, but if you are serious about being a good (read: effective) software engineer, you should strive to understand the code at a fundamental level.

The latter will save a lot of time in the long run because all the time you’d normally spend searching for a similar implementation to mimic? They can be apportioned generously to constructing your own code, code whose inner workings you understand precisely.

The family photo effect

Everyone takes photos with their family, but only those who have their priorities straightened pin them up in their cubicles at work. And with that act comes a family photo effect.

Earlier today I visited a car workshop. I was there to get my vehicle fixed and make an insurance claim after a minor road incident. As you might imagine, it was hard to be chirpy on the way there. I think I made an attempt at being above it deserving of a cookie though.

When I arrived at the workshop, things got better. A lot better. There, I spoke to one of the most pleasant men I’ve met in a while. In Singapore, as it probably is with many cities, an auto workshop is one of the least likely places to meet good people. Most of them are either driven to desperation by poor business or too much business. And the ones in between are often out to make an extra buck off their customers. But not Ah Wah the mechanic manager.

Aside from a conscientious effort to speak in proper English (a sign of learnedness in Singapore), he did something few people, let alone a mechanic, will do. Ah Wah pinned 3 photos of him with his wife and young son on the cubicle wall to his left. These photos were inadvertently on display, which was how I got an open glimpse of them.

These photos made me immediately trust him.

What bad things can a man do when his family–his wife and his child!–are up on the walls of his workplace? Mild ones at most. That’s how I think I reasoned it in my head.

So this is what I’ve learned from Ah Wah: if you want to gain people’s trust, one good way is to show that you care about your family. My logical induction goes something like this:

  1. Displays photos of family proudly at work
  2. Must know what family means, and cares deeply about his/her family
  3. Must therefore understand that everyone has a family
  4. Is significantly less likely to do things at the expense of a member of any family

That sounds about right to me.

Basically, if you can show me, without being coerced or influenced by fashion, that you are willing to let people know your family is important to you by enshrining their photos at your workplace, you’d have gained my trust.

It’s weird when analysed like this, but it’s part analysis, part instincts.