What I learned from my first freelance project

I recently got hired working for a small firm as a freelance C++/Racket developer. They specialize in medical services for clinics and doctors. Since they are a very small team (I think about 6-10 people all together), most of them are biology/medicine majors with only very little programming experience. Their last programming guy quit because they were too small for him, or so they said.

Last week, I had my first small project working for them. Nothing major, just a slow CSV export function that needed fixing, since apparently the export crashed the client's machine - he tried to export a big database of clinical patients, about 10,000. So here's some things I learned while fixing the problem.

1. Reading uncommented code is horrible

I have heard about those mysterious programmers who would never comment their code during my time at university a lot, but never came across any of them until now. The only comments in the code I found where, judging from their content, from another programmer, desperate as I tasked to understand the mystic lines that lay before them. Example:

// Constructor for a new list that recieves an item and has an int-Value
// Frankly, I've no idea what this is good for, but it must have seemed a rather nice idea at this time

So yeah, think of the poor people who will sometime in the future have to read your code and comment it. I was lucky that the code itself wasn't too horribly written, but I shudder to think what I would have done if it was.

2. Non-programmers underestimate your workload

I am required to write a short report about the time I reckon I will need to complete any given project before officially starting work. Because of the horrible, non-commented code, I could not fully estimate what I would have to do in order to fix the problem - just optimize the CSV export, re-write it or maybe even store program's data in a completely different data-structure that was more efficient. All were valid possibilities after about one hour of reading through the code. So I carefully estimated 10 hours, or about two work-days for the task. Upon receiving the report, the higher-ups said that I could start my work, but my estimated workload was a bit high. The answer I wrote them leads me to my third and final point...

3. Using a time-tracking tool is inveitable

... if you're freelance and getting paid by the hour that is. I haven't done a lot of research on time-tracking tools, basically just a quick google search, but I ended up sticking with Klok. I responded with how I was using a time-tracking tool, which would also be able to print a report on total work time, if needed. I would reflect the real time in the final bill, so if I needed only 5 hours, I would only bill them 5. If I ended up needing 15 hours, I would have the software on my side, "proving" my time - proving in quotes because of course someone could just leave the software running while he's watching TV, but let's just assume we're all honest people here.

So yeah, this is basically what I learned from my first short week of working as a freelance developer. It basically ended with me realizing I would have to completely rewrite the CSV export, with which I was about halfway done when I received an email that the client apparently didn't receive any error anymore.. my contact at the firm apologized heavily and assured me their clients weren't normally like this and that I would of course get paid for the hours I have worked until now but still, kind of a funny end, or so I think.