August 11, 2021 - 7 min read
It is a well-known truth that developers hate meetings, SWOT analysis PowerPoint presentations, marketing folks and sleep-inducing daily standups. Behind the cliches, what we really hate is spending the whole day at work and feeling like we got nothing done. (That’s an acceptable sentiment in any profession, isn’t it?)
Even without these time-sinks, you can still work in an engineering team and perform at 40% of your productivity. If too many meetings are not to be blamed, then where did all the time go?
Lack of clarity is what leads you to re-write a feature from scratch and write-off all the time you had previously invested in it - or worse not pick it up at all. A bunch of tickets with vague titles are bound to sit in the backlog for weeks. A ticket explaining the problem statement and where it sits in the team’s priority would get picked up sooner.
When tickets sit in the bug tracker for too long, our eyes learn to ignore them. Go on and take a look at how well the original feature ticket was written or that pesky bug triaged.
The initial ticket doesn’t have to be perfect. The bug may be reproducible only half the times, the database schema can be approximate, the UI design can be suggestive, open questions can merely be mentioned. Follow the golden 80-20 rule. 80% clarity is enough to get started. The rest 20% will come as you implement the feature or fix the bug.
An engineering team that is aligned with the goal of the company will be more effective. For a pre product-market-fit startup, it may be to get the initial 10 customers. For a growth-phase startup, it may be to productize some services or launch enterprise features.
Working on something that doesn’t align with the team’s goal may seem like wasted effort, no matter how thoughtful your implementation or how beautiful your final merge request is.
Great managers will proactively communicate the team goal. If you’re in a self-organizing team, ask yourself: “What is the highest value iteam I could be working on to achieve my team’s goal?”
If you’re always rushing, you’re bound to make mistakes.
Take a breather and look at the problem at hand. Are there any aspects that others failed to consider? Maybe the initial approach has a security flaw, or the UI component wouldn’t work on mobile screens. If you uncover issues like these at the start, you can discuss them to gain more clarity (see point above) about the task at hand. This way you’re hedging against rolling with an approach too soon only to abandon it later.
If you happen to be using functions/classes you’re unfamiliar with, take your time to make sure you understand the existing logic properly.
If you’re a junior developer, ask yourself: do I have the right tools to solve the problem? Corollary if you’re the one assigning tasks: Does the developer understand the area of the codebase they are meant to touch?
Sometimes, your work will have a dependency on others. What I’ve learned works best is to over-communicate. Say what you need and why. Some examples:
Your team-mates may be busy with their own tasks, but they also want to be helpful. All you got to do is ask.
If you’re working on complicated problems, you’re bound to get stuck. The next time you seek advice from a senior teammate, here are some tips to follow:
Reducing the time team-mates spend figuring out what you’re trying to ask is a win-win for everyone’s productivity.
Also, if you have a few tickets you haven’t been able to work on in a while. Ask for help! Corollary: If a bug on a team-mate’s plate hasn’t been fixed in some time and you have some time, pick it up and let them know.
If something is expected by a certain time, make sure that it’s not just in your head. Make it clear and follow up leading to the deadline.
Often there’ll be a sensible reason why that deadline exists. Share that so people working with you are aligned. This is very useful with last minute requests. “Marketing needs this new landing page by tomorrow for the board meeting that’s day after” is more helpful that “Marketing needs this new landing page by tomorrow”.
Schedule the next meeting immediately right at the end of the first one. No need to figure out logistics later.
No matter how much companies want to you adopt the “we’re a big family” narrative, the truth is you’re not. You can be bitchy in your family dinner table and get away with it. Being on edge at work breaks down communication channels and makes everything sluggish. Realize the other person is also trying to do their job and figure out how to get to a common goal for the company.
If tensions are high, just take a break and relax. You’ll thank yourself for the outburst you didn’t have.
Also, if you’re looking after junior developers, remember the three golden words: patience, patience and patience. Take time to teach them. It will pay in future.
As you get into the thick of it, edge cases come up. Things aren’t as simple as you thought it to be. There’s scope creep and feature estimates go right off the window. If you feel like you’re working on something that just keeps going on forever, you’ve got to bring back that focus.
Have a chat with your manager and take a high level perspective on the feature again. You may then decide to commit the extra time on it or ship with the current functionalities and iterate later.
This is a tough one. Why write documentation when you could rather write more code in that time?
Documentation makes sure:
F in the chat for all the things that have been lost in slack messages, JIRA tickets or merge request review comments over time. If you’d like to explain things over and over again when you could rather working on other tasks, be my guest. Else write it down once and just share the link.
Credits: A big shoutout to my ex-manager Puneet who showed me how a manager makes a team greater than its sum. And to my current boss Bhavesh (bk) who is one of the smartest people I know and whose words I have repeated (read stolen) in this article.
If you found this post useful or would love to have a chat about this topic, please message me on twitter!
thoughts about frontend dev, digital experiences and education
Follow me on Twitter