Productivity tips for developer?

By | September 10, 2017

There is a huge demand for productive programmers. Not only are they able to code faster, but they also write high-quality code. However, productivity, for programmers, is highly debatable. A programmer’s productivity is measured using LOC (Line of Code) and the quality of the code written. As productivity for programmers is hard to measure due to project complexities, LOC is used to give a rough estimate.

If you ever wondered how to become a productive programmer, you can read through the productivity tips. They will surely help you to improve your craft.

Why productivity matters

The term productivity is defined as the amount of output you churn out compared to input. Being a productive programmer brings tons of benefits, including higher pay, increased popularity among peers, and internal satisfaction. The mantra is to work faster, keeping the quality of the work intact. No one is denying the fact that a good programmer is more productive than a mediocre one. And, if you want to become a good programmer, you need to take productivity into account. Here is a list of tips which can help you in becoming a more productive programmer.

  • Always have a couple of side projects going to keep your mind sharp. When things at work aren’t keeping you too busy or challenging you sufficiently, spend more time on your side projects during after-hours and weekends. Use your side projects to add new skills to your tool set and experiment with technologies and practices — a luxury you may not have at work, given the usual pressure to get functionality released in the shortest possible time.
  • Continuously refactor your code. Once you’ve got something working, with 20/20 hindsight more often than not you can immediately think of a better way to write the same code. Take the time to rewrite the code in a way that makes more sense. Perhaps add the use of a library to do what you were previously doing yourself. The more comfortable you are with the final code, the more likely you are to continue to add new functionality to it and use it as part of your portfolio (put it on GitHub).
  • Become increasingly familiar with your development environment and tools. Know your editor like the back of your hand. What’s the quickest way to find a class or refactor a method? What’s the quickest way to modify a text file (learn regex). Don’t reinvent the wheel. Know all of the libraries available in the language(s) of your choice and how to use them. Force yourself to write an example with each library. Keep those examples handy so you can review them whenever needed. Once you’re familiar enough with a library, a) you’re more likely to remember to use it when the opportunity strikes and b) you’re more likely to know how to use it and, therefore, resist the temptation to spin your own.
  • Read other people’s code. It’s a great way to learn. If you encounter idioms, libraries, patterns or techniques that seem unfamiliar, explore them further until you feel ready to try them in your own code. Being comfortable with reading code written by others is very important for doing code reviews within your team or across teams, working on open source projects, or troubleshooting open source libraries you’re using in your own projects.
  • Develop what I call a “pixel to Metal” perspective. Eliminate blind spots in your understanding of the entire scope of your application and its execution environment, whether it’s the front end, the back end, the data store, the hardware, supported operating systems, virtualization layers, the network, the data center, or something else.
  • Automate. Automate everything that you do repeatedly including command line (bash profile), text manipulation and log mining (Perl), refactoring (Visual Studio), building, deploying, integrating (Grunt, Ant, Maven, Gradle, Jenkins, VSO), testing (xUnit, SoapUI, Selenium, Postman).
  •  The simplest abstractions are usually best. The real enemy in being productive is the mind of the programmer. The more cognitive load you place in your head, the less productive you become. So complexity is the enemy.  Whenever possible, adopt simple dumb solutions.  instead of multiple iteration through arrays, use smarter data structures. If you can keep it all in your head, you will be faster.  You can’t keep it all in your head if there is this ton of complexity.
  • Think about design before you write code. In my first year I had the impulse to dive into the code right away without thinking too much about the design or the structure. This resulted in a lot of wasted time as the code I produced had to refactored again and again. I sucked at code reviews and had to justify why I wrote it in a particular way. I have started giving more emphasis on code design and structure. It may have increased the time taken to write code, but  it has saved me a lot of time that was previously wasted on refactoring and finding out the source of bugs.
  • Books are your best friends. There is so much material available on the web in form of online courses or tutorials that anyone can start learning and writing apps or games. That has decreased the importance of good books for a lot of people. I also used to think that why should I buy a book when I can learn everything from web. But I was wrong. A good book written by an experienced developer can lead to a lot more improvement than any online tutorial or course. The book goes into the depth of  topics and give you a lot of insights that why the author choose to implement it in a particular way. The book takes you on a journey of the developer and tells you about the mistakes which he made during his working years. This can save you a lot of time if you do not make the same mistakes.
  • Find a good mentor. I cannot stress more on the importance of a good mentor. A good mentor will not only help you to improve as a developer but will advice you on how to proceed in your career. You must try to choose someone who is not part of your team but someone you admire a lot. He/She preferably must have a similar career path that you aspire for. A good mentor can save you a lot of time and help you make important decisions as he might have been through the same things at some point in his life. If you cannot find someone in your company try reaching out to someone on the web. A lot of great developers will be willing to help you if you willing to reach out to them.
  • Keep Your Tasks Organised and Prioritized. I use Redbooth for task management, it helps me to focus and to switch tasks faster. It’s also useful for collaboration with the rest of the team.
  • Don’t Work More Than Your Threshold. If I work more than 9-10h hours, my productivity plumbs and my code becomes exceptionally scary. When you look at the code I wrote after my threshold, you probably say WTF… several times…. increasingly louder. Then, I have to go back the next morning and refactor all the naughty things I did the day before. That’s double work!
  • Write clean and short code blocks.  Nothing is worse than trying to figure out what you did 2 months ago and how it needs to be changed. When you have massive methods and classes, it can be very difficult to figure out what the original logic was. Variable, method and class names are vital to understanding code. Wrapping things into smaller code blocks allows you to make more meaningful names. Our brains can’t hold the complex logic of a 400 line method and often results in hard to spot bugs. I highly recommend Clean Code by Robert C. Martin.
  • Follow the DRY principle. Don’t repeat yourself and if you need to, it’s time to make that specific code reusable. Nothing is worse than trying to maintain code that’s been duplicated multiple times. It’s a huge waste of time and will undoubtedly create bugs. A programmer is far more productive if a change doesn’t need to be applied in 20 different places. It’s also a waste of time for all the other developers who aren’t aware of the duplication. I’ve had instances where I wasted days hunting down duplicated code while making a trivial change.
  • Step away from your code for at least 5 minutes every hour and a half.  An hour and a half works for me, others may vary, but take regular breaks, even if it’s just to walk across the office and stare out the window at an empty sky for 5 minutes, it gives your brain a chance to calm down a little and perform a pseudo semi reset on itself.  If you spend to long concentrating on a singular thing you’ll get the programmer’s equivalent of writers block, I call it “Code Blindness”, don’t know if that’s a thing or not though.
  • If you’re stuck, don’t try to solve the problem. If you’re up against a bit of code that’s defeating you, or you just can’t quite see how you can make the latest crazy requirement work, then don’t try to solve it.  The human brain breaks down under pressure, irrespective of how well you believe you are at “Handling Pressure”, always have at least 2 to 3 other bits of code you can work on, generally something like maintenance tasks or low key projects that don’t require too much thought. You’ll often find that your cognitive process will churn away in your subconsciousness and solve the problem on its own, in its own time eventually leading you to just being able to sit down and solve things in a short space of time.
  • Keep note paper and a pen/pencil near by at all times. You NEVER know when you’re going to get a penny drop moment.  It might be a major vision about some crazy new technology that the world sorely needs, or it might just be a novel way of re-writing an algorithm you created 2 weeks earlier, that you can now re-write to be more efficient. What ever it is, you need to record it.  Be prepared to take notes whenever, wherever. I go through notebooks like they’re going out of fashion, and I have (had until I started scanning them all in to my PC) drawers full of the darn things, I’ve been jotting down notes, ideas potential future solutions for most of my career, and often when I’m looking for a solution, I’ll find inspiration just by picking some notes at random and reading through them.
  • Ask if you suck for more than 15mins. I follow a rule which is if I encounter difficulties and I am unable to figure it out within 15 mins, I stand up and shout ‘help!’
  • When you git commit or TFS check-in, make sure you have clear messages. This point is self explanatory, most of  the times you have to look for the history of changes done in a file. If proper comments are provided while committing the code it makes life easy.
  • Set time limits.  If you know how long a particular project should take you, try setting a time limit around that. A sense of urgency, even from an artificial time limit, can improve focus and efficiency. Ideally, these limits should be set well within the actual deadline you have to work with. That way, you can set aside another period of time to go back and make improvements on what you have already created.
  • Have a superb communication. Make sure you understand what is required but more importantly, make sure you understand what is not required! A lot of times, we as engineers make so much assumption about the requirements and we end up over-engineering the product; spending 80% of our time on the features that actually never needed/asked in the first place. The level of configurability is a common example here.
  • Stop checking your email continuously. I learnt this recently but I realize I had a habit of checking my email every 10 mins and that really destroyed my productivity (“in the zone” moment). This applies to all emails, both work and personal. Close your email client application (Outlook, Gmail, etc) for most of the time. In particular, don’t open email in the morning where you just arrive because that’s your best time to solve difficult problems, fresh from your sleepTypical software developer job doesn’t require split-second reaction so you can afford not to be super responsive with your email. If your job does require it, certainly you will be notified with any other communications (text, phone, etc.) but email.
  • Document your work nicely. Be it code, architectural design, some magic tricks for your compiler, etc. This is really important when you work in a team. A lot of the times, your co-worker will ask you for things that you have explained zillion times to the other coworkers but him. If you have to keep explaining it to everyone, it will suck your time like a black hole. You don’t want to spend too much explaining the same thing over and over but at the same time, you want to be helpful and get respects from your peers.
  • Manage your time wisely. Be selective to your meeting attendance. Just because you are invited to the (technical) meeting doesn’t mean you have to attend it. If you can contribute directly to the meeting topic (i.e. you talk for more half of the meeting time) or if you can learn something from the meeting to complete your tasks, they are good meetings to go. However, if you are there just to nod and nod, affirming someone else’s statements, it doesn’t do any good for you or anyone else. The meeting organizers tend to invite everyone because it’s so easy to do without realizing the damage they have done to other’s productivity.
  • Eliminate distractions. This is huge. The world in the information age is full of distractions coming in every possible way and keeping you from getting things done. I would classify distractions in two main categories: those that we create ourselves and those that are created by others.
  • Do the most important tasks first. As mentioned above, e-mails should never be the first thing to deal with. So, what would that be? The most important task in the list! You have identified the single most crucial task so, you sit down and deal with it without thinking about anything else. Ideally, you should finish this in “one seating”.
  • Do the same thing in more than a single language. The first decent web framework I used was Ruby on Rails, but I quickly realized the inflexibility and moved on. The experience helped me to write a framework in PHP and structure large scale web back ends in Python, picking up the best practices from everywhere.
  • Make it work, optimize it second. A good code is what works with the fewest possible bugs. A better code is a good code which is fast too. But remember, it’s always a trade-off. Speed for Stability. You have to find the sweet spot.
  • Do Right Things at Right Times. If you want to be productive and bring significant value to your company, you should not do random things at random times. You want to do the right things at the right time. You also want to avoid the scenario where you don’t know what to do and you’re either slacking or searching for something in the middle of the day, long after the daily stand-up has been finished. Therefore, plan your working time each day, as early as possible. Take into account all time-consuming activities like meetings or lunch breaks. Limit time-wasting activities like checking Facebook or Twitter to a few short breaks, or avoid them completely.
  • Done One Thing at a Time. It’s not enough to schedule something to do – you want to actively perform well in those activities that are the most valuable to you and your company. This requires keeping your mind focused on the task at hand. You can’t really write a good piece of code or solve a difficult problem when thinking about 100 different things at the same time. Therefore, always do one thing at a time. If you need to get something done in the middle of doing something else, just schedule a “break” from your original task to finish this secondary task, and then get back to your original task. The last thing that comes to my mind regarding focus is that it depletes over time. Of course, when you get into “the zone,” you can sometimes work for long hours without experiencing performance decreases and fatigue, but that’s an exception rather than a rule. Therefore, schedule frequent breaks to regenerate focus and get some rest.
  • Chunk Your Work You might limit your work to a single task and, even then, it might be too much for your mind to grasp. If the task is complex enough, you can’t just sit and start coding right away. You need to know what you want to code and how do you want to code it up. Therefore, start tackling your task by designing a solution and splitting it into small, graspable pieces. That was the first part of the story. The second one is that we want to produce just enough implementation with little effort and a good test coverage.
  •  Involve Other People You might be the smartest guy, with the best time-management system, and a knowledge of all the key bindings in the world and still, there are some problems that you’d find problematic or decisions that should be made by the whole team. Therefore, always involve other people when tackling a problem or making an important decision. Actually, you might not tackle big problems or decisions when working on a task and there’s still room for involving others. Firstly, everybody makes mistakes and we want to have at least a second pair of eyes to look over a solution before it goes to production. Secondly, the documentation and code base belong to the whole team and they should understand everything that’s in there. Therefore, introduce pair programming, code reviews, or some other collective ownership practice to your development process.
  • Get the Things Done-Done. It’s relatively easy to get things done, i.e. implement a solution using the practices described above, but it’s often really hard to get things done-done. What done-done means depends highly on your company’s processes, but it most likely means that the code is either ready to be released to production or actually is released to production. This requires things like approvals, implementing and running some additional tests etc. For your work to start bringing value for the company, someone should take care of these tasks. Therefore, do as much as you can to get your tasks done-done, instead of letting them be stuck with the status “implementation complete.”
  • Take ample amount of rest. Most of us neglect the sleep while working up until late nights. This can lead nervous breakdown. Take time to refresh yourself with at least 6 hours of sleep a day and if possible power naps of 15 minutes to enliven you again.
  • Delegate tasks if possible. If you have team members working on your same project, delegate some of your routine tasks which you can quickly instruct someone else to take responsibility of. Remember to communicate the instructions clearly and ensure they are understood before giving the task to your colleague. Once you delegate something, just a quick review to ensure it’s done correctly and on time is all that you should need to do.
  • Practice Accountability and Responsibility. Every employee needs to be well aware that he is accountable for his actions and decisions, and he can neither pass the buck or pass the blame to someone else.
    • This will help him work more meticulously ,
    • Take cautious rather than reckless decisions, and not take advantage of his place, position or relationship with his superiors.

Leave a Reply

Your email address will not be published. Required fields are marked *