PART FIVE: Organisation
The final part of this series of blog posts is about Organisation. Becoming more organised helped me become more productive at work. I still have a long way to go, but perhaps some of the tips below will be useful.
Write everything down
I’ve mentioned this a few times in earlier parts because it’s one of the most important lessons I’ve learnt: write everything down. Ideally, this will be in a daily log. There are the obvious benefits such as being able to look back and remember what you did or figure out how long you spent on a task, but the real benefits are slightly less obvious. The biggest benefit I have seen is how it enables you to structure your thoughts. It really makes you think a bit differently and often more clearly when you force yourself to write down your progress on a task. Similar to the way rubber duck programming works, writing out your thoughts in plain English can simplify the problem and often yields a solution.
Take the time to automate repetitive tasks such as backups or any checks you might have to do (check a service is running on the server etc.). Not only will this free up your time and make you more productive but it is a good chance to solve problems that might be different to your normal work. It can help you learn Linux tools such as bash and cron, or Windows batch/powershell which are all incredibly useful. You can automate deployment of new software versions using Jenkins, or reduce the number of steps needed for other laborious tasks.
Don’t be afraid to take time to really think about problems. I’m not necessarily talking about regular tasks you are given, as you will presumably have to think about them anyway, but brainstorming solutions to any problems you perceive with other areas of your work can be very useful. These areas could be problems with the company or team work flow, or a particular problem with a particular project. They don’t necessarily have to be technical problems. Half an hour of brain-storming (or even fifteen minutes) can yield results that are worth a lot more than the time invested.
Depending on your work environment it may be frowned upon to not be churning out code at all times. In that case perhaps you can start coming up with some good ideas outside of work in order to justify some “thinking time” in the future.
Leave the folders in a better place
Just as you should always leave the code in a better place than you found it, you should do the same for folders. Whether you have a central server that your team uses for storing files, or if it’s your own machine, make sure to tidy up as you go so you can find what you need when you need it.
Use Git (or another version control tool)
I haven’t mentioned Git, because it’s such a useful tool that most coders couldn’t imagine working without it. I recommend learning to use command-line Git. It is extremely powerful, and while IDEs these days have Git integration, you can only perform a limited subset of possible actions. Whether working solo or in a team, Git will constantly save your life. Here are a couple of Git-related tips:
Git tip 1: Work on code in its own feature branch
When working on a new feature or change, make a new branch and work in there. This means that if you need to make any quick changes and deploy a new version, you can switch to the main branch and have a clean codebase to work in. There’s nothing worse than having a deadline and realising that you can’t make a requested change until you’ve finished and tested the unrelated code you are currently working on.
Git tip 2: Push and merge often
Also related to the above, push your code to a remote repository often (Github, Gitlab, Bitbucket etc.). This may not be so vital on solo projects, but still serves as a useful backup. In a team it means that people can review smaller chunks of code. People might get angry at you for pushing a week’s worth of code in one go as it will take a long time to review it all properly. It also means you can merge the main branch into your feature branch often, which is pretty painless. It saves you doing one big merge at the end because your branch has fallen behind, and it’s here that you risk breaking things as you may not know the context of all the merge conflicts.
Get enough sleep
The final tip of this blog series is probably the least related to coding. Yes, I apologise for intruding into your personal life but this has helped me massively. On week-nights nowadays I have a 10 PM bed time. I aim for 10, and it often becomes 10:30 but that still gives me a good 9 hours of sleep. Since I’ve been doing this I’ve found I can concentrate better, the work days go faster and I enjoy life more! We’ve all had those weeks where we get more and more tired as the week goes on and we’re just waiting for the weekend to come and save us. Those weeks aren’t fun.
Note: Some people don’t need much sleep to function at full capacity, unfortunately I am not one. Interestingly, some experts say that a lot of people who think they don’t need much sleep, are actually wrong, so make sure you get the right amount for you.
That’s the last part of this series of blog posts. It’s been very fun to write and I hope someone finds it interesting and/or useful. If you haven’t read the other parts here they are:
Part 1: Teamwork
Part 2: Flexibility
Part 3: Planning
Part 4: Communication
Thanks for reading, and happy programming.