Work in progress
Anyway, here are my opinions. I believe story points have a way of creating pressure and stress for developers who can’t finish tasks as fast as others.
When individuals are experiencing pain or duress, their thoughts contain defensive ideals. A worried state can manifest as feelings of pressure to accomplish tasks on time, unnecessary comparison to others which diminishes one’s effectiveness, and ultimately, lower quality output. Perhaps fortunately or by design, happy humans produce the highest quality work for the longest period of time 1. My primary goal is to relieve your negativities.
I have full faith, after release of thorns, we continue effortlessly.
The purpose of this document is to outline qualities I believe are important for developers to be consistently happy.
Happiness needs to be the root of our decision making. Teams and systems are recursively built up, piece-by-piece. When the team is happy, we make happy systems. When the team is angry, we make angry systems.
So, how do we make developers happy? And can developers be happy while product or design is also happy? Why not? Let’s do it!
Work when you feel like it, not because you “have to.” Forcing oneself to work is a fast track to burnout. You might be managing burnout symptoms already and are unaware of it. These symptoms include constant fatigue, high caffeine requirements to get work done, less effective sleep, back pain, digestive issues, irritability, etc. When one believes they are doing something they don’t want to do because they “have to do it,” they’re at odds with their internal state. The internal state says no and the mind says yes because it’s fabricated a story to enslave the body.
One cannot deviate too far from the mind or the body, less they attack one another. We need to respect both with equal appreciation. The body knows when you need to stop. We need to listen to it. The symptoms above are the body alarming the mind to slow down.
One might argue developers don’t have the privilege of claiming a task cannot be done by x due date. This is false. The engineers are generally the closest to reality, it’s their job to inform other stakeholders of the difficulty of particular tasks. In that, the developer needs to inform others a task is taking them longer than anticipated or the reality is more tangled than originally believed.
But what if you actually have no idea what you’re doing and a task is taking so long because of learning curves, not the reality of the project. Perfectly fine too, reach out to your leads and describe your difficulties. One day, you’ll be the lead, and then you’ll pay it forward. For now, be selfish and greedy with your time. You need to hone your craft and you will, in time. Your impatience will be your worst enemy. Take a deep breath, you will be a good developer if you keep practicing and keep breathing. There is absolutely no magic. Everything is connected and eventually you’ll see those near invisible details, but for now, rely on your leads.
When are you taking too much of your lead’s time? Don’t worry about it, they’ll either tell you or start missing meetings with you. Both are fine. Again, be selfish and greedy with your education. You won’t have so much time when you start building intimate relationships and family planning.