Things to do when you’re not writing code

programmer at work

If you’re reading this, I assume most of your hours are spent staring at an IDE, coding away. What about the times when you’re not building shiny new features. If you’re lucky enough, then you’re going to have a couple of hours of free time every now and then. What should you use that time for ? So many possibilities. If you want to become a better programmer, then these few hours can be incredibly valuable. I’m here to help you get the most out of that time.

Tinker with your process

This assumes you have a process you follow through your day. If you don’t have a process, build one. A good starting point is the organization process It doesn’t have to be perfect. It’s not going to be perfect. That’s OK. A good process should be a checklist you go through for every piece of work.

What makes a process useful is that it can be improved. So start with something, anything. Now think about your process. Did you miss anything lately? Did you break anything? Does your work take longer than expected ? Did you find yourself waiting for others for extended periods of time? These are all questions you should ask yourself, and improve your process to prevent that! Sticking to a process is hard work, however, it’s worth it!

Read around

Reading is an important part of your work. You should not underestimate the value of information. The world of programming is in constant shift. New frameworks, patterns and technologies emerge every day. If you want to be a good programmer, you should keep yourself up to date with the latest trends. The best way to do that is to read around.

You should, at least, read about the frameworks you’re using. Become a guru on the frameworks you’re using. Look at the documentation. How is everyone else using that framework ? Is there anything you can learn from them ? Reading the source code can be incredibly valuable at times. Take your pick, but get to work!

Think about dependencies

What is the next thing you’re going to work on and why ? More than once, I have started on a ticket only to find out there are hidden dependencies required, assets that I needed (which take forever to track down and acquire).  Think about the next piece of work and the following ones. Is there anything you should do now to save yourself some time in the future ? There are lots of little things that have the potential of costing you lots of time later down the road. The earlier you think about them, the easier your life is going to be. And who doesn’t like an easy life?!

Think about potential issues

The hallmark of a good programmer is the ability to think about the bigger picture, not just what you’re working on at the moment. How does what you’re working on now fit into the whole project? Is the work you’re doing now going to cause any integration issues. I’ll give you a spoiler: Most of the problems with software can be found at the joints. What external services does your ticket (and project for that matter) depend on ? What happens if that service is down, or slow, or wrong or any of the myriad of possible ways of things to go wrong with a service. Catch them early and not only you’ll save yourself a headache (and possibly an embarrassment when the project goes live) and you will prove yourself as an awesome programmer. Two birds with one stone.

In conclusion, if you find yourself with some time on your hands, don’t waste it, use that time to improve yourself, like a knight sharpening its sword before a battle (I always wanted to say that!). Thse thins are valuable in the long run. Instead of stealing some moments whenever you have them, try to make them. Take a break from writing code and improve yourself. You’re going to be better at it! Your project is going to benefit! Everybody wins!

What do you usually do when you have a bit of free time on your hands ?

L.E. As with everything in life, common sense should prevail. This does not mean you should drop important work when important work needs to be done, nor does it mean you should completely abandon your other hobbies and focus on programming 24/7. If you need a break from work, you should take a break!

Soft skills do matter

Let’s start at the beginning: what exactly are soft skills ? Soft-skills, is an umbrella term, covering the less technical skills you need for your work. Stuff like communication, time-management, delegating and other fun stuff you have to do outside of an IDE. I sure hope you are one of those programmers that do consider these skills important. Whatever your beliefs are, stay with me and you might just learn something.

You work with people

Obviously, but think for a second of the implications. Your work is based on other people’s work. People decide your tasks. People evaluate your work. And, ultimately, people pay you for your work. When you think about it this way, it seems important now, to learn how to deal with people. This includes negotiating, giving and asking for feedback. Some of the most efficient programmers I know, are great at working with people. They know what the client actually means when they ask for something. They know how people react when they are given both good and bad news. I would argue that a big chunk of their professional success has to do with their people skills. I’m not saying that you can’t be a good code without people skills, I’m saying that improving your soft skills make you a better programmer.

Prioritize

You are a professional and you should treat yourself as one. You should work on the most valuable piece or work first, and then the next one and the next one and so on. Now, the most valuable task might not be the most fun to do, nor the most challenging. It’s not the work you want, but it is the work you need to do now. Do that! It’s that simple. If you put the project above everything else and you treat your time as a valuable resource (which it definitely is), then, what you should be doing now becomes obvious. Do whatever needs to be done to move the project forward by the biggest margin. Additionally, your time is a valuable resource. Don’t waste it on useless tasks, don’t slack off, and never ever half-ass the work.

Opinions do matter

Imagine this: Someone asks one of your colleagues to recommend an awesome programmer for this cool project they have going on at the moment. Will they pick you? Would you like them to pick you? Be aware of your colleagues opinion on you. There are two easy steps to get there: ask and then listen! Learn what your peers want, what they value and fine tune your discourse to emphasize what they value in your work. Now, this might sound a bit mischievous. My advice here is: be honest. There is no harm in glossing over the details someone does not care about, in order to focus on the details they do care about, but don’t lie to your peers.

Communication is important

If you stop and think about it. During your average workday, you have a lot of discussing to do. Some are not that important, like the ones about the weather, while other matter a lot more, like the ones about your promotion. You spend so much time communicating, why don’t you try to do it right ? Communications  are the result that the sum of all your soft-skills produce. You should start by listening to your manager and try to understand their motivation. Then, you should make sure you work on the most valuable piece of work available. Trust me that will make your manager really happy. Then, think about the way you are presenting your work. Does your manager understand that your task is difficult, does your manager understand that you care about the same things he cares about ?

I know this sounds tedious, trust me. However, the good news is this: these are all skills, and even soft skills can be learned and, when practiced, improved upon.

Be a more productive coder – Some metrics you should use

What does make a good coder ? Is it the number of lines of code they write in a day ? How about the number of works they put in the office? Maybe it’s how fast they code, how quickly they solve any given issue? Well, as you might have guessed by now, I don’t fully agree with any of these statements. Here are some metrics that better reflect your proficiency as a  code writer.

Is your code easy to understand

You should always write readable code. I have an article here if you need a more in-depth opinion on what good code means. Being a productive programmer it’s not just about you. Your part of a team, a team of programmers who need to spend time understanding, maintaining and changing your code. If you have to spend a few more of your minutes to spare a few more minutes of some of your teammate’s time, then you have made the whole team more productive. Neat, isn’t it?

Forget the clever hacks and neat tricks you are tempted to use. I know, it’s hard to give up on a clever little idea you have. It happens to all of us, all the time. When it makes the code hard to read, it’s probably not worth it.

Is your code correct

This should be pretty obvious: Don’t write bugs. What it’s not obvious, however, it’s how costly bugs actually are. Tiny, little bugs cause big overheads. The QA need to file a bug report, it needs to be prioritized, scheduled into the current development cycle (call it sprint, or whatever you are using). Someone needs to pause their assigned work and start fixing it. This means they need to get up to speed with the area of the code the bug lives in, write the fix, review, and the QA needs to test it again. When you think about it this way, adding a few more automated tests and spending a couple of minutes manually testing your code doesn’t seem that bad. Am I right, or am I right?

Is your code flexible

To know if you are doing this, just remember what were your feelings the last time you were asked to change something you wrote. If your first though was: Noooo! Please don’t make me do that!!! then you should pay more attention to this. Keep in mind that requirements change all the time, and that the code is something that is constantly evolving. Therefore, you should write the code on the assumption that you will need to change it at some point, because it’s a safe bet you will. If you spend your time wisely now, you will save a lot more time later. Flexible code is an investment in your future productivity.

An important disclaimer here. Don’t overdo this. It’s a fine line between keeping your code flexible and spending waaay too much time preparing for a change that may never happen. If you are unsure, just ask someone. The PM/tech-lead/client should know how likely a change is, hence they should be able to give you the answer if it’s worth doing it. Design patterns are a good way to ensure you’re not overthinking the issue. Use them!

Summary

In the end, it’s not about how many lines of code you can write, neither about how fast you go through this current development cycle. What makes a good coder is how good they prepare their code for the next issue, and the next and so on. Therefore, in the long run, you are way more productive if you spend some time today to make your work easier tomorrow.

Do you know any other useful metrics that a programmer should use?