One of the very first things you learn as a programmer is that you can’t comprehend every part of a system (at least, not at the same time.) Like with many other complex tasks, we break programming down into simple chunks which we can tackle mostly without concerning ourselves with the intricacies of the rest of the system. What these chunks are varies with specific needs and circumstances, but they are, all the same, bits of problem-space we’ve abstracted away, to be solved and then re-integrated into the final product.

The important thing to note is that this abstraction doesn’t just stop at one step. Each time we break off a conceptual piece of the puzzle, we do the following:

• See if we can break down that chunk into sub-chunks.
• Hook those subchunks together so that the chunk works as a whole.

What’s interesting is that, for the most part, systems design is entirely about putting off the work of ‘implementing’ a chunk, such that eventually, that need disappears. When we fully expand a system, breaking down each piece into progressively smaller parts, what we find is that the real software – the stuff that does the work – is the structure.

But what does that imply for us, as people who create these systems? It means that we need to think carefully about the way we structure our system – the way we break it down into chunks. Too few chunks and you aren’t letting structure handle any of your burden – you may be duplicating code that you could easily factor out into its own chunk; too many chunks and it may be difficult to climb back up the conceptual tree and hook everything together.

It also means that we need to spend time mapping out a project before we dive in, lest we find ourselves neck-deep in shark-infested waters. A little goes a long way, though. It’s not impossible to make these jigsaw pieces fit together, and when they do, you’ve created software that will last.

The use of passwords dates back to ancient times, where they existed as verbal or written phrases that a group would use to verify its members’ identities. Their use has evolved and become more complex since then – it was not until the rise of the personal computer that use of a password to safeguard a user’s personal information would be truly feasible, and even then most users would only have a single password at a time. As any reader of this post will already know, that has changed considerably since the advent of the internet.

With most websites requiring passwords for membership, it is no longer uncommon for a person to need to remember a plethora of different passwords at all times. This is harmless so long as that person has either an excellent memory or unending patience – without one of those attributes, it is unlikely that a user will have a different secure password for each site they frequent. Far more often, users will eschew proper security practices in favor of the convenience of a password they already use frequently. It is crucial that password security is done right on the server side so as to help prevent human habits like common password reuse from becoming a bigger problem than it already is.

We had all of this in mind when we began working on one of our new products, Call Box. We recently had to decide on the best way to allow our first users to change their passwords, with the primary goal being that we wanted to ensure that each password change request is valid before allowing a change. As such, we opted to design a link users can click that sends them an email with a password reset link – the link remains valid only for a limited time before expiring and contains a randomly generated 25 character token string that we tie to the user. We require a certain level of complexity for any password coming in, and ensure that passwords entered into our system are properly encrypted so that the only person who truly knows their password is the person who made it.

These safety features are meant to help keep our users secure, but just as you must wear your seat belt properly in your car for it to be any use in an accident, these measures can only help if users are mindful about how they are adhered. Reducing password reuse and making your password harder to crack are two excellent steps towards ensuring that your passwords are secure, and thus that your privacy is maintained. If a mindful user is paired with secure technology, both will be far more secure that either could be alone.

Last week, we released a new feature that allows users to create advance routing profiles for tracking lines. We offer four types of advance routing profiles for our clients: scheduling, round-robin, bridge and multi-ring. While advance tracking line routing isn’t ground breaking in the call tracking industry or new to CI, the ability for users to create their own advance routing profile is a huge step forward for us. Previously, every advance routing request has to be set up by the CI support team. For example, if a client wants to set up a bridge, they would have to send a message to support and they will set it up for them. The process is lengthy and takes many valuable support team hours to complete. When we decided to revamp our tracking line portal back in October, advance routing profile was on the top of the list in terms of features we wanted to add. The ability for users to create their own advance routing benefits both our clients and our support team. The client will now be able to manage their own routing instead of needing to message support for every little change. This feature will also free up support, giving them back time to focus on other errors that have bigger impacts on the system.

Although we had the idea for a while, the project itself took a while to build. The routing profile was the last part of many changes we were making. Before we created the new routing profiles, we had to make some changes to our database to support the new profiles. We also have to put a lot of thought into how our users will use the profile. When designing the profile, it’s important to think about all the worst case scenarios where our user can use our tool incorrectly. By building for the worst case, we cover all the possibilities where the profile editor can fail. During the coding process, a single page often requires days of testing before we can mark it as completed. One of the biggest problems we ran into was tracking line update speed. When someone updates their profile, it will take some times for the update to reach the phone system from our server. Initially, it was taking hours to update the phone system to match the profile updates. However, after weeks of testing, we managed to trim the update time down to minutes. In the end, we created a user friendly tool that will save both us and our clients valuable work hours.

If you haven’t seen the new routing profile yet, head over to the routing profile page and take a look.

As fast pace and exciting the life of coding is, there are times where the rut sets itself in; the worst part is that you never know how bad it’ll be this time. Alright, I want you to close your eyes and imagine this,(Don’t actually close your eyes, you need those to read) you’re running a maze, it’s super complicated but you’re way ahead of everything. You’re jumping when you need to jump, turning all the right turns and you finally get to the end. There it is, the finish line, you cross it but no lights go off, no gun shots, no applause; just you and the crickets. What happened? Why didn’t you win? You’re then told that you have to cross the finish line with a specific red towel hanging from your waist in order to win; But there are hundreds of towels in the maze. You are then told to go find it and bring it back.

This is like trying to debug some code that you’ve written. You finish everything and you’re feeling on top of the world, you then test it and your world crumbles down fast. Then you’re stuck with this giant, intimidating chunk of code that only you understand best; and you have to find a way to fix it.

Of course you’re going to go back and look for the big things, they’re just the easiest to spot. It’s almost never the big chunks, it’s surprising how often it’s something really small. I’ll give you an example. But the worst part is that the following really happened.

So, as you may already know, I’m a developer for Century Interactive; but I started as a call reviewer in the Humanatic section. This is relevant because in order to become a developer I had to learn to read, write and think code; Of which I had a very minimal amount of (Not remembered) experience from one semester. So I started learning on a great coding training website called codecademy.com. I learned quite a bit but things got really tough when Javascript found it’s way into my life, I remembered very little from that one semester but just enough to know that Javascript is what we were (supposed to be) learning.

So I was working on getting one of the lessons done for my training and I got to the end of it, it wasn’t easy but I did it. I made my final changes and clicked submit; It turned red and said I couldn’t move on until my code was fixed. So I sat back, looked at my screen, and flipped the table. Wait, sorry, that’s what I wanted to do. What I actually did is sit back, look at the screen and scan some of the code. Right off the bat, I don’t see anything so I look a little closer; I find nothing. I continue looking for about an hour, looking things up on Google, taking the hints, and the walk-throughs, everything; Nothing worked. So, it’s about the end of the day now and I go home for the night with the thought of what I’m going to do with that code when I get back to work.

I’m back in the office, sitting at that desk, having a good ol’ fashion staring contest with my computer. I lean over to my buddy Cameron and ask him to take a look(He’s going through the same training). We both look at it for a good 30 minutes, then he gives up so I go back to looking at it alone. I ask him what he thinks I should do and he tells me to ask the CEO of our company who has a lot of coding experience.

So I go up to the CEO and ask if he could help me with something. We walk back over to my desk and I explain the issue. He looks into it for about 10 or 15 minutes and says he doesn’t know, we both laugh and he walks back to his desk.

At this point I feel helpless. I’m frustrated, I swear I’ve grown a white beard down to my chest in the past two days. I just don’t know what to do. I’m staring at all the code, lost. But then, I come across something, something tiny, something so small I wanted to walk out that very day.

Turns out, I’d forgotten to put a semicolon at the end of ONE line of code. I’d been looking for everything except that. So if you take one thing from this, let it be to not overlook the small things.

Meet the Turing Machine, the world’s simplest computer. It consists of an infinite strip of paper separated into cells, a motor for moving between those cells, and a device for changing the information on each cell, or just checking what is currently recorded and using that as an instruction. Also, each cell only contains either 1 or 0, also known as a binary value. This machine, despite being so simplistic, can simulate any computer algorithm ever created.

Of course, this machine is mostly just theoretical. There isn’t much applicable use for making such a machine, and only a madman would attempt to write programs on such a device. But it illustrates a very important aspect about programming.

Computers can complete simple operations quickly, efficiently, and accurately, much faster than a human can. In fact, one of the most computationally wasteful times for a computer is when waiting for input from a human, because it wastes so many cycles just sitting there while you press each key to give it the necessary information to proceed.

This fundamental idea of rapid execution of simple instructions is crucial. If we can automate a process so just the computer can handle it without any human interaction, then the process can be done much faster. This is usually easier said than done, as we humans rarely think about all the minute steps we do to accomplish something we consider simple like going for a walk or having a conversation. But once we have established an automated process, a computer can perform it much faster than a human.

This is why things like Car Wars reports are so useful. You could manually document everything about your phone calls, organize it, compare averages, calculate percentages, draw up graphs, and finally obtain a report that displays your current status in a useful format, but that is a lot of work for humans that doesn’t require a lot of problem solving or critical thinking; it could easily be broken down into a series of steps.

We have a large variety of automated processes happening behind the scenes doing just that to manage the information into these reports. Anytime a user clicks on a report, computers are filtering through data to find what they need, performing operations on it to get things like percentages or max values, organizing it into easy to read formats such as graphs or pie charts, and then displaying the information in an interactive format that allows the user to look through the information and further request changes to display or the information filtered.

This gives the human data in a format that is easy to understand, allowing the identification for trends in activity or problem areas that need to be addressed. And at the same time, it gives the computers a very clear job with definite instructions, which it can use to accomplish this task efficiently in a timely manner. This is the power of computing; having a computer do what it does best, which is fast calculations, while a human does what they do best, which is making decisions and problem solving.

It all starts when we’re told that an application is “broken.” There are many ways for something to be broken, so just saying that doesn’t help us much. We have to ask the client to tell us what they mean. The more details they provide the easier it is for us to replicate the error, and the easier it is to fix.

Our applications have been thoroughly tested before they get to our customers, so any bugs left over are not going to be easy to find. Oftentimes, we’ll find programs that work perfectly unless we follow the exact footsteps of the client.

Once we have replicated the error, we begin our search in earnest. Simple looking websites can contain thousands of lines of code. This is usually the result of multiple functions being written in the same page. If we can replicate the exact error, large swaths of the code can be ignored as they do different things.

After the relevant section is isolated, our job can still be far from done. We first have to analyze the section and check for typos or conditions that may not be met. Even small code pieces can be dense with information that must be sifted through. For complicated blocks, sometimes the only thing to do is remove sections of code and see what breaks. If we’re lucky, nothing breaks, and we might be able to remove the code entirely. If we’re very lucky, deleting it will fix the error completely because not only was it unnecessary, but it introduced the error we’re trying to solve.

Today, however, all the code here is correct and removing sections only caused more things to break. This problem lies deeper, buried on a page that is referenced by the page the client sees.

Investigating this new page, we may find the error, or we may find yet another reference to be explored. Some pages reference multiple files that each must be investigated. Branching paths that are all interconnected, and a single error in any one of them could have a cascading effect on the rest. Only by navigating to each new page and beginning the hunt all over again, can we find the bad code. To say nothing of how long it will take to fix it once we find it.

And that is why you should be patient with your IT guy.

Access to information has never been easier than it is today. Whether it is fact checking a rival or finding a local restaurant, our smartphones have given us the advantage no generation has had before. They have been incorporated into the daily routine, and that isn’t an easy thing to accomplish. If a product can make the things you want to get done easier, then it has value. We never want to stop making it easier for a client to get valuable information quickly. We constantly improve our methods of reporting and one way is by making access available through your smartphone.

We want our products to benefit you wherever you work, and our smartphone app will do exactly that. When you need to check a call, but you can’t get back to the office right away, that information will still accompany you throughout the day. When you move between platforms for your work, you won’t lose anything we have to offer. This wider range of access only adds to the value of our amazing products that drive revenue for you. We are excited to expand our coverage and show our dedication to serving our clients’ needs.

You will receive the same great experience with mobile friendly graphs and functionality you currently enjoy. That is the foremost goal for us, because it shouldn’t add more to your plate. This information will work with your schedule and help keep your customers happy.