You are currently browsing the archives for the Uncategorized category

Removing Noise: My Number One Principle for Software Developer Efficiency

In my experience as a software developer, I have concluded that eliminating noise is by far the best way to increase efficiency. Noise comes in a variety of forms, but let’s define it as “anything that makes it difficult to focus on the problem at hand.”

Code Clarity and Comprehension

Have any of these things ever happened to you when you had to work on someone else’s (or even your own) code?

  • You get a headache just looking at it because it’s formatted so badly.
  • You’re looking at hundreds (or thousands) of lines of code, bouncing around trying to piece together what it actually does and how it does it.
  • It’s not even using the same coding style as other pages you’ve worked on – and maybe you even see varying coding styles from the same developer.
  • It takes you hours to figure it out, once you finally trudge through it all.
  • Your boss keeps asking why it’s taking so long, and you’d explain except you know the last word he or she wants to hear is “refactor”

I’m sure you could add to this list. I’ve dealt with it often enough that I decided to experiment and see how much my productivity improved if I clean up the code as much as possible before making any changes. This involved properly indenting the code, formatting code blocks consistently, adding comments and moving related code close together where possible.

I wish I had charted my findings to show here, but suffice it to say it made a huge difference!

That initial time was not wasted because the code ended up cleaner and more maintainable even before the functionality changed.

By the end of the first cleanup, I was able to understand pretty well how everything worked, and that enabled me to not only solve the problem at hand but usually I was able to refactor a little along the way.

Had I just applied the fix without cleaning up, I would not have been able to refactor much because everything would still have been a mess.

External Distractions

This is another major factor that affects developer focus. Ever been in the middle of a complex problem and someone starts texting or calling you? Especially if the issue riles you up, it can be very difficult to get your mind back on track. You don’t usually need to respond immediately to most things, but often we like doing so even though it kills our focus.

I like the concept of dedicated focus time. The Pomodoro Technique has helped me in this area. Essentially you disregard all non-emergency distractions until your timer goes off, at which time you get a short break and can check and respond to messages.

If you have a noisy environment that distracts you, get a nice pair of around-the-ear headphones that can block out the outside world. Put on whatever music helps you focus, or use noise-canceling headphones and keep it silent. A cheap alternative to noise-canceling headphones is “gun mufflers” used for shooting or working around loud machinery. You can buy these at Walmart or Home Depot for less than $10 and they significantly cut sound. They also sell ones with audio inputs, though audiophiles might prefer my setup: Beyerdynamic DT 770 Pro with the Fiio external headphone amp. It’s sonic heaven when I work now.

Bottom Line

Anything you consider to be “noise”, be it outside distractions, messy code or whatever else – find a way to get rid of it, and watch your productivity and work enjoyment skyrocket!

Please share your advice in the comments – I’m curious to know what tricks other people have used successfully.


Debugging Tricky Javascript Problems Quickly

Often in web application development, developers run into bugs that are not causing a javascript error in the console. This usually happens when their code is simply not functioning to spec, but it can also happen when correct javascript is running so slowly that it “freezes” the application.

When faced with a tricky bug like this, I can get so detail-minded that I forget the broader goal: to find the bug as quickly as possible.

It seems obvious but I suspect I’m not alone as a programmer. I get a hunch as to what’s causing the problem, and I dive right in to that spot in the code. Sometimes I’m right, sometimes not.

Follow your hunch, but only for a minute.

Go ahead and try changing the code you think is causing the problem, if you have a reasonably good hunch. But don’t spend more than a minute or two on this. If it goes longer than that, you will save time on average by skipping to the next step:

Use the process of elimination

Start deleting portions of the code, and refreshing after each deletion, to identify which part of the code is causing the problem. Usually I’ll delete a few sections in succession so as to remove almost everything except the component that had the problem. This would show me whether the problem stems from some of the other code on the page, or a collision with that code.

If the problem still remains, that’s great – I’ve narrowed it down to just that component and can then dig into it in a similar fashion.

But if the problem disappeared after deleting the section(s) of code, then I know it’s somewhere in the code I deleted. I can just “undo” one section deletion at a time and refresh the page after each one, bringing back the code piecemeal until the problem appears.

Once the problem code is found, return to conventional debugging.

When I can no longer eliminate code and have found the problem spot, then I scan those lines to see if anything jumps out at me.

If I don’t see any obvious mistakes, I can go back to using the debug console to check that variable types and values are coming in properly, and step through in as much detail as is required to get to the bottom of it.

If you’ve never used the debug console much, this Firebug wiki page will get you going in no time.

Find slowness culprits using Chrome’s Profiler

Whenever a page has performance problems, the very first thing I do is run it through Chrome’s Javascript CPU Profiler. This shows me exactly how much time each function and method takes, making it much easier to locate problems. Here’s a screenshot of the profiler:

It can be more difficult to work with minified or obfuscated javascript in the profiler, so often times it’s sensible to use it on the un-minified versions of your scripts so you can see meaningful names.

I hope this helps you debug more efficiently!