The best part of coding

Speed. It seems like it’s all we care about. Whether it’s how long it takes for a pizza delivery to arrive or how fast a linebacker can complete the 50 yard dash, people care about things getting done in a timely fashion.

Let’s talk about speed in a programming context. Of course, we want our code to be correct and readable, however just that alone is not enough. Apps that are slow to load data can be painful to use or just flat out useless.

So let’s say you write some code and it’s really slow. How can we make it faster?

The first step is profiling. Profiling is the process of finding out what parts of your code are taking up the most time.

Let’s look at a sample Python script and profile it.

Luckily, Python provides a module called cProfile that can run our script and tell us exactly how much time each function takes. Here are the results:

ncalls  tottime  percall  cumtime  percall     filename:lineno(function)
     1    0.000    0.000    0.096    0.096     scrap.py:1(<module>)
     1    0.000    0.000    0.096    0.096     scrap.py:14(do_stuff)
     1    0.032    0.032    0.032    0.032     scrap.py:4(fast)
     1    0.065    0.065    0.065    0.065     scrap.py:9(slow) </module>

So we can see here that fast takes 0.032 seconds to execute which is roughly half the amount of time slow takes to execute at 0.065 seconds. No coincidence here since slow does twice as many operations as fast.

The only problem with the cProfile output is that it’s ugly. Who wants to spend their life looking at boring text files? I know I don’t. Wouldn’t a colorful graphical display be much nicer?

That’s where SnakeViz comes into play. SnakeViz uses something called a Sunburst chart to display profiling information in a way that pleases the eye. It’s kind of like a pie chart with layers. Let’s take a look at the Sunburst chart for my sample script…

Notice that fast and slow are on the outermost layer because they don’t call any functions. On the other hand, do_stuff is on an inner layer because it makes function calls.

Now suppose that fast called another function called fastest like so…

Then our chart would look like this…

Note that fast actually has two slices. The inner slice represents the cumulative time that the function takes including all of the functions it calls.

The outer slice represents just time spent in fast without calling other functions. In other words, fast’s outer slice represents its internal time.

In summary, SnakeViz is a great tool to find out what parts of your code are taking so long. Not only is it more fun to look at than a boring text file, but it conveys profiling information much more effectively.

Biggest takeaways after year one

I’d like to share some of the key things I’ve learned during my experience as a software engineer as well as the main differences from coding in college vs. the real world.

Know when to ask for help and when to keep trying on your own

I often have a dilemma at work when I’m stuck on a problem. Should I ask my boss for help or keep trying to figure it out myself? It’s important for me to make the right decision and here’s why…

If I keep on trying to solve the problem by myself but I don’t know enough information to solve it, then I won’t be able to solve the problem. There’s a reason why we work together and it’s important to reach out for help when necessary. My boss knows a lot more than I do, and there’s a chance that what will take me countless hours of fruitless frustration will only take him a moment to point me in the right direction.

On the other hand, if my boss just tells me answers to all my problems then it’s an ugly situation because I interrupt my boss from his work, I don’t learn anything, and I become dependent on my boss to figure out my problems. The best way I can become a better programmer is to solve problems on my own. I only like to ask for help when the answer lies beyond my knowledge (and the knowledge of the internet).

The best documentation for your code is the code itself

Back in my college days I used to write a lot of comments in my code. I figured it was the best way to write code because it makes the code easier to understand when reading back over it.

As soon as I took a look over the code on my first day at the job I was surprised by the lack of comments. There were almost no comments. At first it seemed concerning. Isn’t it important to write comments to explain what you’re doing?

However, now it makes perfect sense. Instead of using comments to explain what you’re doing, the code should do that. In fact, comments are bad because they make code more verbose and they can get easily out of sync if your code changes.

Instead of using comments to explain what your code is doing, it’s important to use descriptive class, variable, and function names. These names act as signs and good ones will prevent other developers from getting lost in your code.

Use the correct parts of speech in your code

I never realized this in college but you can make your code a lot cleaner by using the right parts of speech in your code. Here’s the mapping:

• Class→Singular Noun
• Method→Verb
• Variable→Noun

Come to think of it, I wouldn’t imagine doing it any other way. This just makes sense.

Methods should be short

Like 4 or 5 lines max. I remember when I used to make really big methods in college that were probably 100+ lines. By making short methods, it not only makes the code easier to read, but it makes it easier to reuse methods instead of writing duplicate code.

Don’t write duplicate code

By duplicate code I mean that there are multiple places in your code that do the same thing. Whenever there is duplicate code, there’s a problem. First of all, it means there is more code which is bad because it’s harder to read and it’s harder to maintain.

Secondly, if we want to change the code then we have to change it in multiple paces. On the other hand if the code only appears once , we only need to change it in one place.

Write unit tests

The whole field of test driven development and unit testing was foreign to me in college. Now, I can’t quite image writing code without it. Unit tests make sure that your code actually works. I think one problem I had in college is that I would write code without confidence that it does what it’s supposed to do.

Currently I only write new new code if it’s making a failing unit test pass. Also, I’m not scared that my code is broken because my green unit tests are proof to me that everything works. Unit tests are the right way to code and anybody who learns that in college will be way ahead of the game.

Version Control is really useful

Here is another thing that was foreign to me in college, however in the workplace it is fundamental. Version control is the system that keeps track of our code and all the changes that everyone makes to it. It is a tool that allows us to contribute to the same code base simultaneously without overwriting each other’s changes. Also it’s great because it stores all the history of our code, so if I want to see what our code looked like a week ago, I can easily do it. At our company we used to use subversion, but now we use git and I like it much better.

Making progress

Wow, just came bag to update this blog and can’t believe it’s already been 5 months.

Since my last post, I definitely feel more comfortable at the job. I feel a lot less like the clueless dog in the meme, more like a 7 or 8 year old now.

Over the past few weeks, I’ve made a great accomplishment. For the first time since working here, I did something that matters. That’s right, I added code that adds new functionality to our product. Now, when you ask the web app to give you an excel sheet, you can specify whether you want the totals on the bottom or top, and IT WORKS!!!

When my supervisor first told me about this task, it sounded simple. I think it took him about 20 seconds to mention the task to me. At first, the task sounded simple: Get the totals to go on the bottom.

However, I didn’t even know where to start with this. I didn’t know how excel worked. I didn’t know which code was generating the excel. I kind of just sat there dumb-founded for 30 minutes before asking my supervisor “Umm, so where do I start?”

Overall, it was a great learning experience and it was the first project I’ve had while working that I can say that I truly took ownership of and am responsible for the outcome of the product. Whether that means success or failure, it is nice to be able to say: “Yes, I made that”. Even better is that…

1. As far as my coworkers and I can tell, it all works correctly.
2. The code is pretty well organized/structured such that if someone finds a bug, I’m pretty confident that I would be able to fix it.

First month of work complete

Today marks just about my one month anniversary as a software developer at HedgeServ. This picture summarizes how I’ve felt about my day to day work so far:

As you can tell, it’s been hard. I’ve been confused, incorrect, wrong, and clueless. However, I do believe that I’m slowly getting more comfortable with the job. The code slowly starts making more sense and I start feeling a little less stupid every day.

No one said it was going to be easy and while sometimes I feel hopeless, I’d much rather have it too challenging than not challenging enough. I’m ready for the continued struggle ahead.