A few days ago, an old colleague (now a friend) came around.
We laughed and had some jokes for a while until I asked him, "How's working going".
His response led to this article you're currently reading:
"Dude, I am so stressed out!"
Let's call this friend, "John Doe".
John is one of the most hardworking and diligent people I know. He is what you will describe as a "good developer".
He listens. He solves. He deploys. But he's super stressed.
I told him how his attitude of being "the good dev" is affecting his productivity. I reckoned this same issue must be plaguing other developers out there. You may ask, "how's that a bad thing, we all work hard?"
Yes, but the truth is, some of us are too afraid to...
Set Solid Work Boundaries
Being a problem solver is an excellent thing. Almost everything that comes your way is a challenge. This passion is like a fire that gets you praised, promoted, and burnt to the ground.
For many, they have established themselves as the guy or gal who will do it when nothing can be done and therefore neglect their health and wellbeing.
To free yourself, you have to learn to break free from the status quo to an extent. You have to learn to say "No".
The Power of "No"
In my career thus far, I have seen a pattern that keeps repeating. Engineers that can say "No" and challenge ideas are actually the best engineers.
They don't fight every battle. They don't see everything as a challenge. They carefully choose what is worth doing and do it well. Most importantly, they are the most respected.
Why is this so?
Their ability to think differently proves they have intelligence and can see things from a different perspective.
Example:
Sometimes that feature is not worth developing. Learning to skip it for a different, more important feature always proves better in the long run. This helps you prioritize and spend time and energy wisely.
Sometimes choosing to commute to work from home despite what management thinks may just be the **key to unlocking your productivity.
Sometimes resolving an issue may lead to several trade-offs that may lead to an overall delay in the overall project.
You get the gist.
The point is, don't be afraid to draw the line, respectfully. Don't be afraid to give your opinion. No, you don't have to be rude. You just have to be reasonable and logical. You have to ask yourself, every time, what action is worth the time spent on it.
You may think adding that feature may take 30 minutes. But that's 30 minutes you could have used to resolve that pending ticket that'll lead to your company reaching its objective.
You may think commuting to work may help your boss acknowledge you are productive. But that time could have been used to deploy a new feature, learning about a new technology or skill.
Conclusion
Being a "good dev", is likened to being a "yes man!".
While you may think that may get you popular, promoted, praised, and recognized, it may also lead to severe burnout and being unproductive for a long time.
Everything has a cost - an opportunity cost. Time is a finite resource, spend it doing things that make your life and that of your company or client easier not harder.
Learn to factor in the opportunity cost and trade-off of any action before execution. Most importantly, learn to communicate and articulate your points in a logical manner so your clients, colleagues, and team members can understand and see things from your perspective.
How about my friend?
Well, let's just say he's looking for a job elsewhere. He's too afraid to communicate and set boundaries and that is making him resentful about his job. He thinks salvation lies in the next job. It most likely doesn't. It's best he finds out himself.
Kindly share your thoughts and comments. I'll learn to learn from your experience.