Posts for 2023

Today, let's talk about Quiet Quitting! It's a term that bloomed into massive popularity back in the September of 2022, when TikTok users started using it to advise people to avoid burnout. Stop going the extra mile. Stop going above and beyond. Do what you're paid for; nothing more, nothing less.

Predictably, the Internet erupted. All over Social Media, people were discussing the merits and drawbacks of this phenomenon. People were outraged, or intrigued, depending on which side of the fence they were on. But what I consistently saw, was the utter lack of nuance. The concept of Quiet Quitting was either decried, or lauded. There was very little middle ground.

And perhaps today, we will find it.

First of all, I want to discuss the positive side of Quiet Quitting. There are definitely some use cases for it.

Self-preservation

Everyone's made of flesh, blood and bone. These have limitations. There's nothing intrinsically wrong with pushing yourself to the limit and perhaps beyond, but these things have a price. And the effects will become apparent the more you push.

Doing the bare minimum for certain periods of time, helps you replenish your very limited mental and physical resources. This keeps you longer in the game, and ensures that you do not arrive at a state where you've burned out and it will take you an extended time to recover.


Remember, by the time you discover the need to rest, it's usually too late. Get in the habit of resting early and resting often. Employers will consider this lazy, but as a French author once said...



No one can go in Beast Mode for too long. It's neither practical nor humanly possible. You are going to have to establish some professional boundaries, or your body is going to do it for you. Trust me; when that happens, nobody wins.

No skin in the game

Employers are quite rightly attached, both professionally and emotionally, to their companies. They have skin in the game. Their fortunes rise and fall with those of the company.

Employees, however, do not. For all practical purposes, a job is just a job. A software developer does not cease to be a software developer just because this software developer works in Company B instead of Company A. This is what employers need to realize. Expecting employees to have the same amount of commitment as themselves, is both supremely illogical and self-serving. Employees who go the extra mile, need to be doing it to further their own agenda; whether it's upping their game, gaining the experience or just a personal obsession with doing a good job. The moment you start thinking that you're doing it for your company, you lose. Because that is a game where there is only one winner - and that winner is not you.

But if it's a reward the employee is hoping to get from all that extra hard work, the reward needs to be guaranteed. Improving in skill and experience is guaranteed. Doing a better job is a guarantee. A promise of a bonus or promotion is not. It's merely a possibility, no matter how fervently the employer says otherwise.


This reminds me of when the wife and I were on our honeymoon in Bangkok. We were in a mall, and I left her to get a foot massage while I went off to look at soccer jerseys. When I returned, she was being treated like a queen by her attendant - drinks, cut fruit, pillows. This was mind-boggling considering we'd taken the cheapest package and no other customer was getting the same treatment. My wife smugly informed me that she had tipped her masseur, and I was mystified because I knew for sure she probably would not be the only one doing so. Ah, said my clever wife, but I tipped him before the service started!

See, any fool can dangle a carrot. But if you reward someone in advance, the probability of them doing their utmost to earn it, is too high to be ignored.

Efficiency

In a previous blogpost, I mentioned that Laziness is the foremost virtue of a programmer. That is because the very basis of our work centers around reduction of human labor. Therefore, working extra hard to achieve the same result is not only counter-productive, it is antithetical to this profession.

A programmer working extra hard probably has something to prove, and it's not a good look.


Any sensible employer will tell you that an efficient employee is always preferable to a hardworking one. Unfortunately, some employers feel that they are entitled to both - they want an efficient employee who will also go the extra mile.

No employer is entitled to the extra mile. That is complete rubbish. If it were the employer's entitlement, it would not be called the extra mile.

Thus, for starters, the goal should be for the employee to be able to complete the work in less time, at an acceptable standard. Any employer who considers that "stealing" from the company is probably operating from the viewpoint of paying for the employee's time rather than the employee's output. That, once again, is antithetical to the profession of a software developer.

All right! We've gone on about how Quiet Quitting could help you, and why you should really consider it. But it's not a silver bullet, and as I like to say, there are no blanket solutions. I would be remiss if I did not discuss the negative side of Quiet Quitting; the situations where you shouldn't.

Slippery Slope

So say you've decided to do only your job, and nothing else. That's fine. But how far does one go? Playing games at work once done? Taking extra-long breaks? Spending an entire day goofing off? Where do you draw the line?

I've observed that this is a very human flaw: we don't know when or where to stop. And we definitely don't want to go too far with Quiet Quitting.


There is a very real danger that once you start Quiet Quitting, it becomes your default mode and then the quality of your work starts to slide. Professionally, one should always opt to be just a little uncomfortable. This encourages growth. And that may entail venturing outside the professional boundaries you have set up. Remember, don't think of it as doing it for your company. It's a lost cause. Think of it as a training exercise for you to up your game.

In an industry where change is the norm, Quiet Quitting can be detrimental to a software developer's professional growth. Working for the sake of working is silly. So is slacking for the sake of slacking.

Substitute for actually quitting

Another reason not to engage in Quiet Quitting is to do with the reasons for it in the first place.

Do you hate your job? Is there a sense that you've come as far as you're ever going to go? Are you Quiet Quitting because it's preferable to risk of leaving this job and settling in at a new job?

No, it's not preferable, and software developers do themselves no favors by Quiet Quitting as a substitute for leaving for greener pastures or a fresh challenge. If you stay too long in a comfort zone, that comfort zone becomes your prison. Who volunteers to stay in a prison?


Yes, there are other factors at play. Perhaps there are mouths to feed and a lack of opportunities. But this is the tech industry and opportunities are plenty if one has the wherewithal to look for them.

Know when to Quiet Quit, and when to actually quit.

Refusal to lose

Some employees view their relationship with their employers as an adversarial one. From their perspective, the employer wants as much work done while paying as little as possible, while the employee wants to earn as much money as possible while working as little as possible. These goals are diametrically opposed.

Thus these employees view the act of putting in extra work, as losing.


A change of perspective is needed. While getting your work done to a certain standard in as little time as possible or giving the company not a minute more of your contractually stipulated time are admirable goals, it's possible to take this too far. Sometimes, putting in a bit of extra work is a professional duty. Sometimes, deadlines have to be met. Every once in a while, it won't kill you to try your hand at something else other than what you're familiar with.

Of course, if you find yourself constantly in a position where you have to give extra, then it's probably less of a you problem than it is a company problem. But extreme scenarios aside, being in perpetual Quiet Quitting mode is not ideal. Give and take.

Late last year, I was in a position where I was writing a complicated SQL query that was supposed to pull data into a report for an audit. The problem was - these figures did not balance. I slaved over it an entire week, and finally the deadline was in the morning. At 8 PM, after I'd given up for the day, while swimming laps, an idea struck me. I was pretty confident it would work, but resolved to get to it first thing in the morning. Professional boundaries, amirite?

Only, later on at 11 PM, I found myself restlessly tossing and turning in bed. I couldn't let it go. I had to try out my solution. I logged into the portal, painstakingly went through the process of testing my solution, and it worked. My joy was unspeakable as I applied the solution and finally went to sleep, at 1 AM in the morning.

Was I working hard? Was I going the extra mile for my company? Looks like it, but here's the thing - I wasn't doing it for my company. My company and my employer were the last thing on my mind when I crawled out of bed and went once more unto the breach. I could have waited till morning; it would have made very little difference. But the part of me that I suspect is a part of programmers all over the world, simply would not rest till I'd gotten it done. It had become personal.

My employer does not know I that put in that effort, and in all likelihood, he never will. It doesn't matter. I wasn't doing it for him.

Last words

Don't work hard for your employer. Do it for yourself. Whether you slog or you coast, your first and foremost objective needs to be yourself. It's your mind, your body, your career, on the line. Your company will get on just fine, and if they don't, it's not your cross to bear.