In this article, we will look at a few hacks which can enhance the productivity of an individual or a team.
All these ways are sustainable to follow and work well when incorporated as habits.
1. Reusing tools and knowledge
One of the biggest mistakes people make is to start from scratch and re-invent the wheel.
When faced with a problem, the first step should be to look for existing solutions.
If an exact solution is not found, the target should be to compare the requirements to similar solved problems.
Find similarities and differences.
Reuse what you can and more importantly, document the new findings on every iteration.
This is effective on a personal level but works even better when done on a team or organization level.
Successful organizations spend a lot of effort in enforcing this re-usability which in turn helps their developers to be more productive.
2. Speed over Perfection
While perfection can be a target in some cases, speed is usually mandatory. Perfection on a high level design is not a bad idea, but it starts hurting the speed when it's desired on every small detail.
Delivering quality depends a lot on doing a lot of repetitive and trivial tasks correct and quickly.
Here are a few ideas to achieve this.
Delegate without micro-managing
As developers, out state of mind is always to provide solutions. This becomes tough when you're dividing work with other people.
While it's good to care about the big picture, it's a waste of time trying to ensure others are performing their tasks according to your thought process.
Trust the other person to do their job without you being involved at every step. Their output may not match your expectations for the first few times, but it gets better after a few iterations.
It helps them figure things out on their own and they build a better working relationship with you if they feel you trust them.
Have an Acceptance Criteria
Establish an acceptance criteria early to give an idea of when to stop. The maintainability and adaptability of your code is also a part of this acceptance criteria.
When you write down your target, it makes it difficult to overthink and over-engineer beyond it.
Meeting this criteria is the first target of the developer. It takes priority over refactoring and making code look pretty.
Reduce Review Cycles
Build guidelines that a team follows rather than relying on long reviews. This should be done for both code and processes.
Use automated code quality and testing tools to validate PRs rather than a reviewer having to do it manually.
The best way to check the feasibility of a solution is to build a prototype and test it.
Focus of the prototype should be to test the risky and unfamiliar parts of the solution.
Once its successful(or unsuccessful), it is important to document the new findings.
It is not required to do extensive research, long courses of study or multiple rounds of planning before getting your hands dirty with the code.
Working code brings more confidence than any notes, documentation or minutes of the meetings.
4. Power of the people
Whether you work in a team or build a product on your own, it is important to leverage the power of the people.
Doing it all alone is not a good idea. It makes your chances of success limited to your own efforts.
Here are a few things when you should consider involving other people:
Asking for advice
If you know someone who is good at the skills or problems you are trying to conquer, ask for their advice. Learn how they do things. Build upon their knowledge.
Validation and feedback
Let your team or friends validate your ideas and give feedback.
The earlier you get someone else's perspective on what you're about to do, the more time you have to make it better. Feedback at a late stage is not always helpful and harder to incorporate.
Ask for contributions
Ask people to contribute in whatever way they can. They could share the workload with you, fix some bugs, review your code, or even help you with the design.
Working on ideas together is a great way to get ideas flowing. It is a way to learn new approaches to solving a problem. It can also bring constant validation and feedback.
Sharing knowledge can build a community of like-minded people. It helps you network and builds trust.
It can unintentionally lead to people pointing out flaws in your implementation or documentation and getting you to fix them.
Everyone should take planned periodic breaks and reflect on their progress. This is similar to a sprint retrospective and let's use the same principles for our personal reflection.
Here are a few things to consider in your reflection:
What can you do better?
Focus on saving time and effort by finding opportunities to optimize the little things you do every day.
Find opportunities to automate processes. Find ways to clear out the junk. Improve your work environment (physical and software) to support the plans you have for the near future.
What's hurting you?
Reflect on the habits that are keeping you from getting things done. Find a sustainable way to reduce the time you spend on those habits.
It's also important to figure out your mental blockages. Pending tasks and annoying people weigh a lot on your subconscious mind and you are better off without them.
What's working well?
Reflect on the things that are going well for you. It could be beneficial to invest more time and effort into it.
If you work in a team, it's important to share this with people who's productivity affects yours.
Thanks for reading. If you found this article useful, consider sharing it with your friends. I'd also love to know your own advice in the comments.
And if you want to connect with me, you can find me on Twitter
Top comments (0)