Avoiding Programmer Pitfalls
Programmers love solving problems. The issue is that most times we are functioning on a lack of information. Within our minds we model a systems and processes that allow us to abstract away the need to think about any one specific piece all the time.
When we are building new functionality or when a hard to replicate bug is discovered it will set you down a series of paths and decisions that, if explored, sometimes, but most often won't directly solve the problem. Instead it will help to illuminate or inform future decisions and actions that need to occur.
This gif demonstrates how a simple premise like fixing a small issue can lead you down an endless path of decisions.
So how do you avoid these innocuous time sinks?
- Assess priority
- Give yourself a time limit (15 min)
- Asking for help
- Only productive interruptions
- Structure of day
Assessing priority of the issue
A personal rule that I use is: quickly estimate the amount of time I expect researching or solving a problem I am having will take. If it will take more than 15 minutes, then ping my team.
Give yourself 15 minutes to solve a problem
If your assessment is that this problem will take less than 15 minutes, then go ahead, but first set a timer for yourself. If you haven't solved your problem within 15 minutes, then immediately ping someone on your team.
Sometimes you are working alone, or the team isn't available while you work in your timezone. This is where a simple self enforced timer can help rein in time easily spent wasted on SO.
Pinging your team for help
The goal of a team is to move quickly and build high quality products. The goal of everyone on a team is to enable their team members to move quickly. Communication is key and
The math works out too. Generally speaking a team of developers are generally highly paid. If a teams time is worth say $100 per hour, and a quick chat provides enough information to avoid 1 - 2 hours of another developers work then it is "worth" it in a financial sense.
If someone knows a system better than you then it even helps to set aside time to explore the system and ask questions together, and at the beginning of a project under taking.
Avoiding interruptions
Can a team that constantly interrupts each other work? In the short time some structure should be put into place to increase a programmers chances of success -- this means proper hand off, a deep enough system brief, and an open invitation to ask questions. In the long run it pays dividends because programmers are not spending time googling around in futility and have their heads spent less in understanding a system and more in sovling problems or improving products.
I am not a big fan of persistently on chat applications like Slack are, becaude there is a constant mental overhead for checking on conversations that slowly saps away your ability to stay focused.
Structuring your day
Although I am not a fan of everything Paul Graham does or says, his post on the Maker's vs Manager's Schedule resonated with me.
If you're an independent contributor building, debugging, designing, or problem solving, then it helps to keep your day broken into as few larger chunks possible.
I personally like to break my day into two major blocks with lunch separating the halves.
This gives you roughly 2 3-hour chunks of uninterrupted time to work.
For management types who work with software developers or designers, figure out how the folks on your team prefer to schedule their meetings. Some folks might want meetings late in day, early in day, or closer to their lunch breaks.
If you've ever had trouble focusing on deep techinical problems because of a dreaded upcoming meeting, then you'll know how important communicating and finding the right time for meetings can be.
I learned about the 15 minutes or ask a team member bit from my friend Nikhil.