Simple Tricks to Improve Coding Efficiency

There’s a strange phenomenon that has arisen among software publishers.  There appears to be a tendency for people to invert their understanding of what makes a quality product better, or at least this is true when it comes to those who do the marketing.  It goes something along the lines of: “Their product has one million lines of code, but ours has two million, so therefore our product must be better.”

No-one knows where this “more is more” kind of thinking came from, when back in the day everyone was working so hard to create a “less is more” philosophy.  Probably it started with consumer-grade journalism, because many writers try to impress audiences by quoting big numbers.  For most things, this works—this tiny flash drive holds 200 terabytes of data, that CPU can process 48 billion instructions per second—and writers aren’t always technologically savvy enough to understand that the same doesn’t apply to source code.

But efficiency in coding isn’t only about creating tight algorithms.  It’s also about being able to reduce waste.  This means waste in terms of how much time you spend fixing problems, waste in terms of consuming too many computer resources, and even waste in terms of how many pizza boxes your team has stacked up around the office by the end of the week.  Ideally you want to cut down on all these things.

So what we’ll take a look at in this article will be the things you could do to improve efficiency and increase productivity.

1. Build a conducive work environment

Every coder is working in unique circumstances, and our readers are a very diverse bunch, so it will be easier for some of you to implement these suggestions than for others.

If you’re a freelancer, congratulations, because you’re already master of your own work environment.  Of course that’s going to change when you go to visit a client and have to work on-site, but it’s still a sweet position to be in if you can make a success of it.

If you’re the manager of a development team, these suggestions can also help to get your team to maximum efficiency.  Or if you are a worker on a development team, you may want to suggest some of these ideas to your manager or at least send him or her a link to this page and hope for the best.

Consider allowing team members to telecommute

Programming is partly an exercise in logic, but it’s even more of a creative challenge.  The best programmers can employ either side of their brain in equal measure to any task.  Science has long acknowledged that creative people do their best work at night, and it’s something we’ve all experienced.  So why do most managers insist on a traditional 9 to 5 routine?

Actually, we already know the answer to that.  It’s partly about control, and it’s partly about making things more convenient from a business point-of-view (or at least a management one).  But that insistence on routine and location is hurting the efficiency and productivity of the team.

What you need to realize is that your coders were probably up all night trying out the latest game, or maybe they went partying, or simply had to socialize with family.  It means that when they turn up for work on Monday morning, not only are you not getting them at their peak productivity level, but they’re already drained of energy and dog-tired.

Giving workers a choice about when they work—and ideally also where—is an excellent way to improve productivity and morale.  As long as they get the job done and turn in excellent qualtiy results, you shouldn’t care about when, where, or how they achieve it.

The exception is when you need close collaboration, but in truth most coders do better when left to do things in their own way, and the need for close collaboration is rare.  The option to come into the office should still be there, but there’s no realistic reason why it should be required unless you’re working on top secret military projects.

As a freelancer you can also see the key point here is that if you do most of your actual coding work at night, you’re likely to get more done.  There are fewer distractions late at night, it’s quieter, and you’ll feel more creative.

Avoid music

We’ve all seen those crazy movie stereotypes where some super-grungy überhacker puts on their headphones and jams along to death-metal while effortlessly churning out screenfuls of code without even stopping to breathe.   And all of us who really code in the real world know how ridiculous that image is.

But if you do listen to music while working, be careful.  It’s quite easy to find yourself thinking about the music instead of your work, and some kinds of music can have a soporific effect.  When you go for a workout at the gym, the right kind of music might inspire you to push out that extra few reps.  But no-one has ever managed to create music that will inspire you to find the line with the missing semi-colon, or to make the correct choice between using a for loop or a while loop.  The closest we’ve ever got to that is Electric Dreams.

Try to keep tidy

Clutter can be oddly comforting, but it also can slow you down.  You can easily lose 20 minutes looking for something that’s been lost in the mess, and then forget why you wanted it in the first place.

So, for all the inconvenience it causes, why are we—some of us at least—so addicted to clutter?  Organizational expert and author, Julie Morgenstern, claims it is because this stuff connects us with our past and plays a role in defining our identity.  Marcus Geduld, a teacher and stage director based in New York City, suggests that it’s because clutter is preferable to a “sterile” environment, and likens the chaos of clutter to an affirmation of freedom and creativity.

There is, however, no doubt that reducing clutter will help you avoid distraction and disorganization.  As such, it is a worthy goal to accomplish.  By all means, keep a few sacred objects around that make you feel better and less stressed, but don’t overdo it.  Decluttering is one of the hardest things to do for most people, and it’s not just our physical desktops that need decluttering, but often our computer desktops too.  If you really struggle with that, you could try using a minimalist DTE such as Fluxbox, which doesn’t really allow you to have any clutter.

But in the midst of all this tidying, don’t go overboard.  There’s plenty of good science suggesting a bit of chaos in the environment may actually be conducive to creativity.  One of the most frequently cited bits of research into this is a journal entry in Psychological Science by Vohs, Redden & Rahinel for the University of Minnesota titled Physical Order Produces Healthy Choices, Generosity, and Conventionality, Whereas Disorder Produces Creativity.  Probably the reason why this is the paper journalists cling to is that it clearly concludes that: “…participants in a disorderly room were more creative than participants in an orderly room.

Much less popular are dissenting views, such as  Environmental Disorder Leads to Self-Regulatory Failure (Chaye & Zhu, 2014), published in the Journal of Consumer Research.  This study found that people working in disorderly environments were impaired in their ability to perform tasks.

So where does this leave you?  Should you work in chaos or sterility?  The answer seems to be to find a balance where it’s just chaotic enough to keep you inspired, but not so much that you get distracted or have trouble finding things.

Leave some room behind you for pacing out your thoughts

It’s a good idea to have plenty of room for wandering about when you’re deliberating.  Many of the best admirals and generals in history were renowned for the extensive time they spent pacing about the deck while planning battle strategies.

Not only fighting men follow this practice.  Many Buddhist monks also advocate “walking meditation”, and believe it helps promote clarity of mind. Whenever you have a particularly knotty programming problem to solve, you may find it helps to stretch your legs a bit with a meditative walk around the deck.  Obviously here again a lack of clutter will help you to do this without ending up in the hospital.

As a boss, take a cautious approach to criticism of creative efforts

There’s nothing wrong with constructive criticism, but you need to pick the right moment and approach it in the right way, or it can backfire by making your staff less productive in the future.  Rather than inspiring them and providing insight, you may actually make them afraid to take risks, which is a good way to kill off creativity.  Marieke Roskes, in Constraints that Help or Hinder Creative Performance: A Motivational Approach, provides a framework for how to deal with motivation of creative workers, and specifically also how to avoid unintentionally demotivating them (Creativity & Innovation Management, Vol 24, Iss 2, 2015).

2. Establish a good SOP

There’s a lot of catchy trends in business management and programming procedure that sound a lot more sensible in theory than they turn out to be in practice.  Whether a particular approach works for you or not depends on your objective, and what you personally consider to be a successful result.

One example of a methodology that a company I worked for tried—and just as quickly dropped—is pair programming (not to be confused with PEAR programming).  While some people really admire this work methodology and praise its place in the agile development paradigm, we found that it was terribly inefficient.  For a start, it required two programmers for every workstation, so you were paying twice as much for less actual development work.  We also found that it was much slower to work this way because of the frequent stop/start flow and the tendency for unnecessary dialog.

The advantages of pair programming were that it did result in more natural documentation and stricter documentation.  It also allowed bugs to be spotted more easily and for suggestions to be made about tightening up an algorithm.  At the same time, however, the same advantages also created problems because sometimes the tweaks and adjustments weren’t really necessary.

Another risk with this approach is that you can get the effect identified by Roskes, where programmers might be hesitant to try things because they don’t want to be corrected.  You may find personality clashes flaring where one developer is very pedantic and traditional, but the other is more creative and spontaneous.

Programmers often state that they prefer pair programming.  It’s possible that this is because they enjoy the social interaction that it affords, but this contributes nothing to the efficiency of production, except perhaps as a morale booster.

So what you need to establish is what actually works for your developers and what doesn’t.  For the things that don’t work, it’s better to discard them, even if they’re a hotly trending practice.  Whatever helps the team to make progress quickly is a good thing.  But if they’re weighed down with a methodology that doesn’t suit their style, it will eventually lead to problems.

3. Encourage verbose documentation

While it may seem that verbosity would increase inefficiency, the small amount of time it takes to give more detail and precision in comments can save a lot of trouble as the project rolls along or undergoes revisions.

4. Discourage unnecessary documentation

Well-written code is often self-documenting.  If it is perfectly obvious what a function does from the name you give it (which should nearly always be the case), then adding more description is superfluous.  The same goes for variable naming and return values.  It should be clear from the name what they do, and in those cases where it’s not possible to do that, you ought to include a description of them in comments.

5. White space is your friend

Using white space appropriately in your code is valuable in helping to make code easier to read, review, and understand.  It goes hand-in-hand with good documenting and writing self-documenting code.  It should be possible for any experienced programmer—or maybe even a non-programmer—to pick up a copy of your source code and instantly understand what the purpose of each function is and how it works.  Ideally, somebody should be able to learn to program from nothing more than studying your well-written code.

6. Prefer simplicity over complexity

The more complex you make your code, the more difficult it can be to untangle it.  Ironically this applies to programming shortcuts, like using shorthand conditionals instead of writing them out in full.   It saves time in the writing, but a less experienced programmer coming in to review your code later may not understand your intentions.

7. Test exhaustively

Code should be tested incrementally and often.  Before deploying anything, you should conduct as much in-house testing as possible, even if your first release will be designated Alpha.

8. Use version control

You’d have to be crazy not to use version control on a major project.  Without it, you aren’t protected from your own minor mistakes, and also it’s really easy for another team member to accidentally (or intentionally) sabotage your code by overwriting it with something that doesn’t please you.

By taking these eight key suggestions into account, you will be able to develop you own strategy for extracting the most efficiency for you and any team members you work with.  You don’t necessarily have to apply all of them, and certainly some may not even be practical for you, but any combination of them is likely to result in you getting your work done with less hassle.  A more productive workflow will pay for itself over time, even if it is just in terms of stress reduction and giving you more time for yourself.  That’s a goal worth working towards.

Emma Grant

Emma Grant is a professional freelance content writer from Ireland. Over the past three years she has travelled the world while running her business from her laptop. You find her at www.florencewritinggale.com

Leave a Reply

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

Rating *