Engineers don’t move the mouse!

Somewhere back in 2009-10, my then employer Google had decided to move to Apple MacBooks for everyone based on ‘security considerations’. As I switched to a MacBook for the first time in my life, I was struggling to navigate my way and spent almost a month or two learning and training myself on all the multi-touch, multi-finger swipes and trackpad gestures to get up to speed (pun intended!). That was until my teammate who saw me moving my fingers rapidly across the trackpad come and tell me in front of my entire team — “Vinodh, engineers don’t move the mouse!”.

As much as I was embarrassed, I could not agree more with him. He was essentially telling me that this was a lot of effort and I should just be learning keyboard shortcuts going through friction-less air than this friction-filled navigation on the track-pad as shiny and smooth it may be. It was basic physics. Something as repetitive as navigating windows all through the day should be done with the least energy required. 

Mother of your Inventions

Extending it further, I have no qualms in saying that engineers ought to be lazy. Well, ‘lazy’ in the sense that you need to optimise your energy — after all you are an engineer.

Engineering is all about optimisation in a way. In fact, engineers should get bored easily. I know that seems quite counter-intuitive.

But the point I am trying to drive is that as engineers, you have to build products and technology that get rid of repetitive stuff.

However, there is a lot of repetitive work that you can’t seem to get away from. I think the way to get out is to build a platform or something reusable the moment you realise that you are being asked for something similar again and again.

Somebody asks you to pull out some data — if they reach your desk maybe for the third time, stop pulling out the data. Write a script or an API endpoint and hand it off to them. And make it generic to pull all kinds of data if you have different people coming to your desk with different demands. Essentially, make laziness and boredom the mother of your inventions!

H-index

Another thing I would advocate is to never build throwaway code or systems. Always build for reuse. When you build for reuse, it becomes a component ready for integration. I also know that clean code always gets associated with more time, and quick is always assumed to be ‘dirty’.

I beg to differ — if you always build for reuse, every time you write new code, it will build on top of something you already built, making quick and beautiful, but you have to just make it your default way of doing things. In fact, you will be surprised at the inspiration you get from seeing your work getting reused. In fact, the entire scientific research community works that way.

I am just reminded of a rather funky metric called the H-index, which sort of measures the overall impact of a scientist’s research publications. For example, how often did your research work get used in building something new? Because understanding the impact pushes people to keep discovering new things that can become the foundation of something newer.

‘Abstract’ Engineering

The last point I want to talk of is abstraction. Abstraction is an intriguing concept— an higher order thinking ability that helped humans pull away from the pack of fellow animal species, including the Neanderthals over the last 50,000 years. I know that we apply abstraction to a lot of things in life. Now do you (remember to?) do it in the context of what you build day-to-day? Because if you can abstract things out and implement stuff, you have evolved as an engineer! That is higher order engineering. 

Essentially you are no longer building for mere reuse, but building for recycling. You have pulled away from the rest of the engineering pack, so to say. You have built an abstract framework/library. Now, not only can your components be built on top of it, so can other components/use cases that you did not imagine and those of the future too — standing the test of time, beyond those sales demos or even the flagship product of your company as abstract frameworks and libraries tend to have the longest shelf-life. In fact, I think abstractions serve purposes far greater than an elongated shelf-life.

A classic example of this is the story of Amazon. In the early 2000s, as Amazon engineers worked to clean up their data centre and API mess to scale to the ever-burgeoning traffic of their e-commerce website, they ended up abstracting out their entire computing framework and data stores. At that point, little would they have imagined that this was going to be the foundation of a totally new line of almost seemingly unaligned business that would get them to profitability a decade later — Amazon Web Services. Probably the most successful idea of recycling ever.

R, R and R

To summarise, as you might have rightly guessed, follow those 3Rs — reduce, reuse and recycle. Reduce your effort and time in doing things, build for re-use and ultimately recycling.

In fact, the concept of 3Rs is a topic close to my heart in other ways too — something that I have campaigned for in Bangalore in the context of waste management ever since my visit to the landfills of Mandur. But then, I guess this is one abstract idea you can keep recycling all your life!

(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)