There’s no time for anything. At least that’s how it feels doesn’t it?
It’s early in the morning. I’m tired for spending most of the night editing a podcast (checkout the Stream Team Show), I’m on a quick session to write 375 words today. More about that over here in this blog post about the X-Card Technique. Now I want to spend some time improving my programming skills, but first I should spend time with the family. I’ll do some coding tonight.
That’s how it normally goes. There feels like there’s little time to stay ahead of the technical curve. Little time to refactor that ugly section of code written a few weeks ago. Deadlines coming up we can fix that later right? Little time to write documentation. Little time for much of anything!
With so much going on you might think that burning some midnight oil is the right thing to do. Trust me it’s not. Understanding the following few truths about time management for a developer has saved me many sleepless nights.
1: Trying To Learn Everything Is Never A Good Idea
You should always ask why do I have to learn this stuff?
Don’t get me wrong you should always be learning, but what you focus on can have a big impact. If you find yourself losing sleep chasing every new technology, framework, and feature don’t worry because you have a lot of things that are working in your favor.
The good news is that most new technologies will never gain traction. Regardless of what the headlines say, not everything takes off like most say. The numbers are in your favor.
Companies don’t quickly switch their tech stack. Most are already heavily invested. Not unless it’s a small and nimble startup. Your career is still safe.
There are a few tried and true things that you should worry about learning:
- Master Current Stack — By Stack I mean the main parts of your development ecosystem. This could also be the main technologies that your company uses. There’s probably a computer stack that you tend to use more than others. In fact there’s probably a stack that you use everyday. When new versions of the tools come out it’s a good idea to learn them. These are the tools that you use to help bring food on the table.
- Technologies Backed By Market Leaders — If you are looking to learn a new technology you might want to focus on something that’s backed by a market leader. If Google, Microsoft, Apple, or Facebook come out with something that starts to gain some traction it’s worth looking into. The only reason why I would suggest this is because it’s less likely to fade away. Market leaders have a lot of power to change trends.
You want to set aside time to learn. Mark it in your calendar and treat it like a doctor’s appointment. It doesn’t have to be a long session. Even just 15 to 30 minutes add up over time. I would recommend doing something daily but end the end you should find what works best for you. Being consistent is the most important thing.
Here’s another post on finding what to learn next that can help, if you’re having trouble coming up with ideas on what to focus on.
2: Write Great Code The First Time
It might seem quicker to just throw something together that gets the job done, but it’s not. Writing bad code will eat up a lot of time down the road. You’ll spend a lot of time trying to remember what was done if step away from the project for a bit. It becomes very hard to debug bad code when something goes wrong. In the long run it’s just not worth it, and by writing great code from the start you can help prevent yourself from burnout.
Time spent on a feature includes time spent refactoring and working other code around any poor design decisions you made when implementing that feature.
When you start looking at total invested in your work in this way you’ll start to realize that spending time upfront to implement a good design is well worth it in the end.
Here are two things you can do to help reduce the errors in your code:
- Build Iteratively — The common mistake that programmers make is that they either spend too much time up front thinking about how they’re going to solve the problem with starting. The second is that they don’t spend any time improving their solution after it just works. Follow the mantra first stated by Kent Beck: “make it work, make it right, make it fast” — and in that order. Coding iteratively allows you to bake in this approach into your working sessions.
- Use Test-Driven Development Or Something Similar — You want to use a coding style that will help reduce the number of bugs that you’ll have to deal with in the future. TDD could be a good choice for this (even though I’m struggling to implement it myself). Another option to make sure that you have sufficient unit test coverage for most of the code that you write. Most places that I work don’t even merge pull request into the project that don’t have at least some unit test added with them.
3: Avoid Hero Syndrome
Avoid the hero syndrome. Hero syndrome is when you try to take on everything by yourself. I’ve been on a college basketball teams that had self proclaimed heroes.
Whenever the game was down to the last few minutes they would try to carry the team to victory by themselves. However in a team based game like Basketball unless you’re skills are clearly above everyone else’s like a Kobe or Jordan, it’s more efficient to play as a team.
What would have been better for the team would be to follow the proposed game plane so the everyone’s on the same page.
Grinding tell you’re burnout doesn’t make you a hero as a Software Developer. Managing your expectation does. Trying to be a hero all day every day just leads to burnout for most mere mortals. This burnout leads to missed deadlines and a reputation as inconsistent.
You need to take back control of your time. Getting to the place where we consistently deliver the highest quality work exactly when you say we will is where we should strive to be.
This is going to take a lot of work, and you’re going to have to push back a bit when people demand unrealistic timelines. After you show your trustworthiness most of that resistance will go away.
Becoming a real hero will help build a reputation for timeliness and reliability. While most burnout you’ll be able to stand the test to time by managing expectations.
4: Take Some Time Off
Taking more breaks will boost your productivity. John Trougakos, Associate Professor of Management at the University of Toronto, says, job-related stress can kill your productivity. He suggests that, “disconnecting from work can do wonders for people’s energy and mindset.” To prove his point, he references a study wherein 59 percent of people surveyed said more breaks would improve their work happiness.
Your mind and body need down time, and they’re going to get it whether you like it or not. So, schedule that down time. Actually plan and put on your calendar real scheduled breaks. This will allow you to take down time without feeling guilty about it. It will make work-time easier to endure because you’ll know that you have a scheduled break right around the corner.
Don’t Burn The Candle At Both Ends
As Software Developers you might feel that you have to work around the clock to keep up with a rapidly changing landscape, but that doesn’t have to be the case.
You can grow your skills and still live a balanced life most of the time. It’s all about time management.
How do you manage your time so that you can continue to learn? Let me know in the comments below.