Complicated code bases. Bare-bones specifications. Tight deadlines.
If these sound familiar, you’re not alone. Software development is a difficult field to work in, despite being one of the fastest growing in the United States. Developers burn out quickly and often. In fact, one survey shows burnout rates of nearly 60% among tech workers.
In this post, we’ll look at six important reasons why you might burn out, and what you can do to make your work a little easier.
6: Managing Multiple Projects and Expectations
Developers often juggle multiple projects and tasks simultaneously. At times it can seem like everyone needs your time — even other developers. Knowing where and how to allocate your time is essential for meeting deadlines and avoiding last-minute crunches.
Unfortunately, estimating effort is one of the hardest skills for developers to learn. Projects often look easy on paper, but fall apart during development. Quick fixes can turn into long nights. Countless variables such as design problems, integrating with other systems, red tape, and unexpected bugs can hinder progress.
Meanwhile, managers and stakeholders want deliverables as soon as possible. Move too slowly, and you’ll get pushback. Move too quickly, and you risk overexerting yourself, burning out, and sacrificing quality. Learning to compromise is important, but requires you to be honest with yourself and aware of your abilities.
What Can You Do?
Start by tracking the amount of time you spend on tasks. Use tools like Toggl, Clockify, or Kimai, and review them during your next Sprint Retrospective. Once you understand where your time is going, see what tasks you can cut out or delegate to others.
If the scope of work seems too large for the current iteration, or threatens a hard deadline, push non-essential changes to the next sprint. This is especially true for minimum viable products (MVPs), where lengthy development cycles can put the final product at risk. With practice, you’ll be able to manage projects and tasks more effectively.
5: Not Having the Right Resources or Requirements
Developers need resources, and unfortunately, we often don’t get what we need. Systems, IDEs, access to environments, specification documents, shared knowledge bases, a decent workstation — without these, you’ll be stuck before you can even write a line of code.
Specifications and requirements are particularly important and often missing. Writing code without requirements is like building a house without a blueprint, and almost always results in wasted effort and technical debt. Requirements provide a clear direction and establish consensus for everyone involved — as long as everyone sticks to them.
What Can You Do?
Reach out to your team for any resources essential to your current work or overall role. Send written requests (email, Slack, and so on) to your team lead, and schedule reminders to follow up if they take too long to get back to you. If you still don’t get the resources you need, ask if the feature requiring that resource is truly necessary, or if it can wait until the next iteration. And always be sure to mention your blockers during stand-ups. Keep your team informed and aware of all problems.
When it comes to requirements, take the extra time needed for proper review. If there aren’t documented project requirements, insist on getting some! Interview the project owner and key stakeholders to understand the purpose of the project. Don’t commit to a task unless you have a complete understanding of the work.
4: Understanding Complex Systems
An organization’s codebase can have decades of combined work from dozens or hundreds of different developers, each one bringing his or her own coding style, decisions, and level of (or lack of) comments. You’ll likely inherit code that is confusing or downright incomprehensible, and requires a serious time commitment to understand and unravel. Hopefully, your code is under source control, perhaps the single-largest advance our industry has made in the last decade on understanding the history and rationale of a codebase. If it’s not, your confusion will be magnified.
Even with a good understanding of your code, using third-party products often means learning entirely new APIs. Commercial products make your job even more challenging by masking their inner workings, which makes debugging unexpected behaviors even more difficult.
What Can You Do?
If this is a new project, make sure you’re familiar with the team’s coding practices and standards. If you’re stuck on a particular module, set aside some distraction-free time to step through it and write down any unanswerable questions that arise. If possible, pair up with a teammate who’s more familiar with the code base, ideally the original developer or maintainer. For third-party products, don’t hesitate to use documentation, FAQs, customer support, chat rooms, and community forums. When all else fails, Google (or DuckDuckGo) it!
3: Keeping Up With Technology
Change is the only constant in software. There are always new tools, programming languages, and best practices to stay aware of, regardless of your level. Even just maintaining code means staying on top of product updates and security bulletins.
Of course, nobody can be an expert in everything, but developers are expected to know which tools are suited for which tasks. Developers need at least cursory knowledge of multiple technologies and tools to better evaluate different solutions and avoid choosing the wrong tool for the job. The amount of new skills and technologies you need to understand can be overwhelming.
What Can You Do?
Stay on top of your technical game by constantly learning new technologies and practices. If you can, schedule “discovery” days where you don’t work on your current project, but rather spend your time researching and learning about new technologies. When learning a new service, take advantage of free trials and educational materials. Consider contributing to open-source projects to practice your skills outside of work. And always remember that new is not always the answer — don’t get distracted here when looking at a project. Choose the right tools for the task, which may or may not be the shiny, new ones.
2: Balancing Communication and Interruptions
Constant communication between developers, team leads, and other departments is essential for keeping everyone on the same page. However, too much communication can have a detrimental effect on productivity. Developers already spend 21% of their working time in communication tools, costing companies nearly $30k per person per year. All of these interruptions cause context switching, which makes it even harder to focus on your work. It’s estimated that it takes up to 20 minutes to get back on task after an interruption.
Why interruptions are catastrophic to developers. © 2018 Monkey User. All rights reserved.
What Can You Do?
When coding, eliminate distractions and dedicate yourself to the task. If you find yourself constantly dealing with interruptions, then signal to coworkers when you are in “focus mode”. Schedule “no meetings” or “untouchable” days on your calendar just for coding, wear headphones, and change your status in communication tools. Once you are focused, think critically about the problem, evaluate it from different angles, research multiple options, and plan out your implementation strategy in advance. Document your decisions (as well as your code), and be prepared to justify them.
1: Feeling Like You Don’t Belong
Despite their education, expertise, and experience, as many as 58% of tech workers suffer from imposter syndrome. When a developer faces a task that pushes their abilities or challenges their self-confidence, he or she might question their ability to do the job. This could lead to a negative feedback loop that eventually ends with the developer becoming disengaged at work, or even quitting their job.
Not belonging is especially difficult for underrepresented groups. In the United States, as many as 80% of developers are male, 58% are white, and ageism, unfortunately, is still common. These biases — deliberate or otherwise — can discourage skilled developers and deter new developers.
What Can You Do?
Don’t isolate yourself! Engage with the development community: network with other developers, follow industry leaders, and attend events. Use the opportunity to share your knowledge, collaborate, and learn something new. Remember, everyone feels this way at times.
Embrace Your Strengths
The most important thing you can do is be honest with and trust yourself. Overcome your fear of failure and branch out of your comfort zone. The more you try new things, the better you will become at determining what your strengths are and where you can improve, which in turn will build confidence. Trust yourself to make the right decisions, but don’t be afraid to reach out for help as well. It’s tough being a software developer, but with the right attitude and effort, it can be an incredibly rewarding experience.
Top comments (1)
So so so true. Good thing there's a lot of material to learn how to TRY to be better estimating and also how to prevent ourselves from giving bad estimates.
However, many of devs(including myself) only find this material after we've suffered the problem.
Or try to add some practices and standards. Add docs were they lack. Try to leave the project better than you found it.
Well, really nice article. The reason I always gave about "why software is so difficult" is because of lack of specifications but the reasons listed here are really valid.
Bookmarking for future reference 😁