Quiet Quitting: Do Or Do Not? (Part 2/2)

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.

Know when to stop.

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?

Don't get stuck!

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.

Don't want to lose.

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.

Just my quiet opinion,
T___T