If you are passionate about your work, your day to day duties in your job can be incredibly pleasant. I personally love being able to code daily, whether it be writing new features, bug fixing, or refactoring. However, all of those tasks become stressful when under pressure. If you’re not in a management role, then you likely have very little control on how projects are managed and how estimates are given. If your team doesn’t have a consistent metric for measuring complexity of feature requests or bug fixes, estimates can be hard if not impossible to give. There is only so many factors we can control, but part of being a professional is identifying those factors. Here is a couple that have become important to me when coding under pressure.
1. Knowing your limits
It’s easy to make mistakes when sleep deprived and mentally exhausted. Working long hours day after day can ultimately be counter productive. Make sure you find a balance or you will burn out. I’ve always found it difficult to “turn off” when a problem hasn’t been solved. Though many times it’s when I stop thinking about a problem that it magically becomes clear what needs to be done.
2. Time management
When faced with a list of things that need to be done, proper allocation of your time is important. For example, performance optimization. In general, I’m speaking of code that sits outside of the realm of high performance computing. Would you rather have something that works slowly and gives you the right answer, or works faster but gives you the wrong answer? Don’t get bogged down trying to optimise if you don’t have time. Note that optimise later doesn’t mean write clean code later, you should always strive to write clean code even if it’s not an efficient implementation.
3. Personal velocity
Part of writing software is estimating how long it will take you. Even if your team doesn’t use velocities, you can still gather data from tracking system and version control software to calculate your own personal velocity. Brian Tarbox and Heather Mardis wrote a thoughtful post about this, “Retrospective Velocity, When Will This Project Be Done?“. If your lead comes to you with a project and a deadline, you should have a quantitative way of estimating how long it will take you and inform them whether or not it is possible and find a compromise in the latter scenario.
Start small, pick something you have control of in your development environment and try to improve it. Whether it be finding a better way to juggle work and life or finding a balance between design and implementation.