Ep. 29 - Finding time to become a better developer

There’s no time for anything. At least that’s how it feels doesn’t it? No time to refactor that ugly code, no time to work on documentation, no time to actually live your life. But if you take the time to listen to this podcast, you’ll find yourself with more time for what’s important.

Written by Bill Sourour: https://twitter.com/BillSourour

Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

Original article: https://fcc.im/2rqbKAp

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

There’s no time for anything. At least that’s how it feels doesn’t it? No time to learn all the things you think you need to learn to stay ahead of the curve. No time to go back and refactor that ugly piece of code. It works (sort of) and there’s a deadline approaching. No time to write unit tests for everything. No time to write documentation or comments for the next guy who gets stuck maintaining what you wrote. No time to think. No time to breathe. No time!

Well… if you take the time to read this article, I promise you’ll find yourself with more time for what’s important.

I used to think that the only way to be a great developer was to work myself sick. My health, friendships, and family all suffered because of it. Understanding the following 5 truths about time management for a developer is what saved me.

1. You don’t need to learn every new thing in order to stay relevant.

There is no question that a good developer should always be learning, but where you focus your learning can make a huge difference in the amount of time it takes to stay on top of your game.

“The old thing is dead. Long live the NEW, about-to-be-old thing!”

First of all, don’t get suckered in by headlines on dev blogs that announce a new standard every 37 seconds. Most new technologies, frameworks, and features will never get any real traction and you’ll never need to know them. Those that do emerge will take a lot longer to gain adoption than the blogosphere — and the vendors who hock these new technologies — would have you believe. Companies are invested in their tech stack and, other than a handful of tiny tech startups, they can’t just turn on a dime. So, relax, your career is safe.

Focus your learning on three areas, in the following order of priority:

Fundamentals — It’s a lot easier to pick up new skills when you have a real command of the underlying fundamentals. For example, if you understand JavaScript deeply, you can master any new JavaScript framework in record speed. If you understand Object Oriented Programming deeply, you can master new object oriented languages quickly, too. Deeply learning the fundamentals will 10x your learning efficiency. Always focus on improving fundamentals above all else.

The latest version/feature of the stack(s) you use the most — There’s a stack of technologies that you probably use every day. These are the tools that will put food on the table for you and your family. When new versions of these tools are released, it’s worth investing the time to learn about them.

In-demand tech that is backed by market leaders — if a big, well established company like Google, Facebook, or Microsoft puts out something new and it starts getting some buzz, it’s worth looking into. There were a hundred and one JavaScript frameworks all vying for attention and then Angular and React showed up and wiped them off the map. I’m not saying there won’t be disruptors that come from nowhere and become the next big thing but, more often than not, no-name tech is just noise.

Learning time should be a part of your schedule. Set aside a specific amount of time for learning every day. It doesn’t need to be a lot of time, even 25 minutes of reading and experimentation every day adds up quickly.

2. Writing good code takes less time than writing bad code, BUT it doesn’t feel that way.

You probably feel like the time you spend on a new feature ends when you run the code and it appears to work. But that’s just the beginning of your time investment. Time spent on a feature includes time spent debugging that feature later and also time spent refactoring and working other code around any poor design decisions you made when implementing that feature. When you start to understand your time investment this way, it becomes obvious that, in the long run, fewer errors and better design are a worthwhile investment.

There are two things you can do that will reduce errors in your code and lead to better design.

Use test-driven development. Write the test first, then write the code that satisfies the test. This not only leads to less buggy code but also to better design, because when you have to structure code in a testable way, you end up making smaller, simpler functions that have fewer dependencies.

Use an iterative design approach. Don’t spend time trying to make code perfect before you’ve spent time trying to make the code work. You’ll never, ever get it right completely in your head. You have to get those fingers banging on a keyboard and produce code that runs and does what’s expected. The problem is that developers tend to make one of two common mistakes; either they spend too much time thinking and not enough time actually doing, or they don’t spend enough time improving their first solution. Follow the mantra first stated by Kent Beck: “make it work, make it right, make it fast” — and in that order.

3. Working 24/7 does NOT make you a hero. Managing expectations does.

This is the one that nearly killed me. I used to agree and commit to any crazy timeline my boss or client could come up with. I was afraid of saying “no.” I was afraid of letting anyone down. I would do whatever it took to deliver. I have literally slept under my desk, and pulled multiple caffeine-fueled 40+ hour marathon coding sessions.

At first I was a shining star. I would get a big pat on the back and I felt like a hero. But I set an expectation that was impossible to live up to. Working like that is unsustainable. Eventually, I started to burn out, get sick, and miss deadlines. I started getting a reputation as unreliable and inconsistent. It was bad news.

What I eventually came to understand, and what you should commit to learning too, is that the real heroes are the ones who are consistently reliable. They say what they’ll do and do what they say. The only way to be that kind of hero is to manage expectations.

You need to take control of the timelines so that you are always and without fail delivering high quality work exactly on time. This is incredibly difficult at first. It means having to say “no” and having to push back.

In the beginning, your boss or client won’t be thrilled by your resistance, but once you demonstrate that you are trustworthy and reliable, everything will start to change.

Over time, other developers will be late, deliver sloppy work, or burn out and become unreliable. Then you will become the real hero of your team. In fact, learning this made me one of the most in demand consultants in my market. I’ve built a stellar reputation for quality and timeliness, because I vigorously manage expectations.

4. Not all time spent “improving” code has the same ROI.

Spending time is an investment. Like all investments, it’s reasonable to expect a return on investment (ROI). You should be getting back at least as much — and hopefully more — value than you put in.

We talked about “make it work, make it right, make it fast.” It’s a good mantra but there is a trap: “right” does not mean perfect, and “fast” does not mean absolutely as fast as possible.

“Right” means that the code works consistently and is easy to refactor. “Fast” means that the speed of execution does not have a negative impact on the overall user experience. The most important thing is that your application feels fast to the user.

So, don’t waste time trying to shave time off a function that is barely used, or trying to save another few milliseconds on something that already runs faster than a human can blink (~300ms). And don’t waste time trying to refactor working, well-structured code because you just learned some new technique or approach that you’ve convinced yourself you suddenly have to go back and apply to everything you’ve ever done.

5. Scheduled down time makes you more productive.

This was a very hard one for me to learn and accept. How can you possibly be more productive when you’re not spending all your time producing? Well, it’s true.

According to Allison Gabriel, an assistant professor of management at Virginia Commonwealth University who studies job demands and employee motivation, “There is a lot of research that says we have a limited pool of cognitive resources. When you are constantly draining your resources, you are not being as productive as you can be. If you get depleted, we see performance decline. You’re able to persist less and have trouble solving tasks”.

Always working sets off strain reactions, such as stress, fatigue, and negative mood. These drain your focus and your physical and emotional resources.

The brain’s ability to self-regulate — to stay disciplined — wanes with each exercise of self-control during the day. It’s a loss of resources that must be replenished. Otherwise it becomes harder to stay on-task, be attentive and solve problems.

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.

More help and resources

To help you even more, I’ve put together a list of free and useful resources (videos, tutorials and websites) that can help you better understand and implement the insights I’ve just shared with you. You can get it here: https://www.devmastery.com/signup/time/index.html

 

Episode source