If you have a programming blog you have to write a post about programmer productivity. It's kind of like a ritual to be accepted into the pantheon of programming bloggers (next to writing your opinion on the industry and how it has changed as a whole).
Productivity in programming is weird when you are starting out. You think that you aren't making any progress when you just play around with HTML and CSS, because those aren't ReAlll programming languages, when in reality you are learning the basics for whats to come. You can't properly learn how to make web apps with just JS because eventually you are gonna run into some problem that requires HTML or CSS knowledge at a much deeper level. So you are making progress I assure you.
The type of productivity I'm referring to is how to properly get something done that you have set out to do and not spend hours just watching tutorials. What I'm saying is that to me productivity is when you are actively moving towards a goal. You don't have to consistently move towards the goal, yes it is prefered, but not necessary as long as you are moving. There is this great quote that I don't know the source of anymore, but it says It's much easier to steer a moving train than a not moving train. Once you have some momentum towards the goal all you have to keep doing is correcting your path to the finish line.
Taking development as an example. It takes ages for someone that hasn't programmed before to actually become really productive, but they are still productive in some sense. They are learning and learning takes a very long time to make into production of value. And that sucks, but it sucks all the time because we as developers are always learning and consiquently always feeling like shit because we don't 'know' enough. It's something that comes with the job.
Here are a few things I've learned to make me more productive in the work environment :
Having a list of tasks
I was using Trello for the longest time as the default home for all my tasks that I had to do at work. It quickly became clear that Trello was no working, because tasks were always changing and I was being switched to different projects all the time, making it difficult to constantly change Trello entries. Instead I actually downgraded to a regular A4 piece of paper, where I write the project name at the top and then tasks that need to be done. I cross them out once the tasks are done and it makes it easier to draw out UI requirements and make diagrams for easier understanding.
Also one of the reasons why I use paper is because we don't do development on laptops and making notes on my phone is just annoying at meetings.
Understanding the importance of a task
Using the Eisenhower method you should go over your tasks and decide their priority. If you have 2 critical and important tasks, analize both and figure out which one will take the longest and do that one first. This sounds easier said than done, because a lof of the time you can't really know how long it will take you to finish a task, since programming can have a lot of unexpected bumps in the road. Plan accordingly and if the task completion time goes into the red, talk to your manager about getting some extend time since it's in everyones best interest to have work done at the end of the day.
Knowing when you can get the most done
For me mornings are the most productive times of the day. I love programming in the morning with a cup of coffee by my side, the earlier the better. That comes at a cost though. I just can't be as productive after lunch as I am in the morning, I feel like crap, no concentration, irritated and want to go home. It's just the way I'm wired, but I have to force myself to do work untill about 4-5pm. Management doesn't care if you can't programm after 2, stuff needs to get done. So know yourself enough to know when to schedule the most important and hard tasks for the day.
Slow down
This is something I'm working on myself, but hear me out. Do everything 25% slower. Why? Well you can do 10% the point is to slow down. Programming and development is a tricky thing and small mistakes because of rushing happen all the time. So slow down, check what that function is doing, do you have all cases handled and test the shit out of it, so you can be certain when push to production happens you didn't make a simple mistake because you were rushing. For me it helps to really think about the problem and solution before diving in and solving it. You can't predict everything that might break your system, but slowing down might cause you to see something you otherwise wouldn't if you were just rushing through.
Thank you for reading!
Top comments (1)
Good advice. Step three is definitely the one I forget the most! I feel like there's so much to learn, I'm in a race against time, but I need to slow down and I'll actually get more done that way.