10 Lessons I Learned from My First Freelance Project
Listen: I am no professional. I am a computer science student, currently in my first year. Between January last year and now, I undertook what I would call my greatest accomplishment so far: I developed a piece of software, from start to finish, on my own. I learned a lot; I probably learned more about programming, and myself, than I ever have. This is why I have decided to write this article — to reflect, analyse, and inspire. (Okay, inspire is a bit optimistic. Let’s say motivate).
Let’s set the scene. I went straight into university education in September 2014, with a decent set of A-levels in my pocket, and my head held high. Having studied Computing at A-level, I knew that I wanted to be a programmer. I wasn’t sure what exactly I wanted to do, but programming was definitely my calling. I started studying for a degree in Computer Science, a natural starting point. This was when things started to go downhill.
Due to a number of factors, I ended up having to retake two exams in the summer of 2015 (damn you, Java). Much to my dismay, I ended up failing one of these, and being thrown off of my course. This was definitely the low point of my, admittedly short and relatively cushy, life.
I made the decision to take an ‘unplanned gap year’, since I had no other option. After a month or so of an unsuccessful job hunt, I ended up taking up a voluntary position as an IT Support Assistant in a special needs school. My time there was productive, educational, and I fully enjoyed myself. I had planned to stay there from October to the Christmas Break, but I ended up staying there for the rest of the academic year, until July 2016. Here was where I got my first real life programming ‘job’. I was tasked with creating a booking system for resources in the school, such as rooms and laptops. I wrote it using PHP and a MySQL database. I had only had a bit of experience in PHP and SQL from my first year at university, but this was a real test of my skills, and I ended up learning so much.
This is not what this article is about, however. It was my first taste of paid programming, having sold the software to a neighbouring school for a whopping £100. Having completed this task, the person I worked for gave me a project from a company that he knew. They were a cardboard tube manufacturing company, that was looking to update and upgrade their quotation system. I willingly agreed to this, with the promise of a payment in the thousands of pounds range, which to me was reason enough.
In my naïveté, I thought that this would be a ‘quick buck’, and I thought that I could get it wrapped up within a few months, well before I started university again. However, this was not the case. It ended up taking just over a year. It was during this time that I learned these lessons, lessons that have helped me improve as both a programmer, and a person.
Planning Is Everything
Do not ignore the systems development life cycle! It is there for a reason!
When I started this project, I was given an A4 printout of a document, which contained two sections. The first outlined the general calculations used by the system, and the second was the source code of the existing system, which was written in the completely outdated Visual FoxPro language. The reason for the company needing a new system was because the original system was written in the late nineties, at which time I was just a toddler. The original system was becoming sluggish, due to the high number of records in the database, and it couldn’t even be run on 64-bit computers (each employee had to use two computers each, one to run the system, and the other to complete other tasks).
I was eager to get started, so I dove straight into Microsoft Access, to try to transfer the quotes from the old database files, to a new database. After about a week of messing about and not really getting anywhere, I realised that I needed to use a programming language to create a properly functional program. I ended up using C# .NET, due to its similarity to Java — which I was fairly familiar with.
My idea of ‘planning’ and ‘design’ was scribbling diagrams in a notebook, and writing poorly formed functions. This led to me creating a fairly shoddy first prototype. It was pretty ugly, and the functionality was very limited, but it worked as a proof of concept. I ended up ditching the use of Windows Forms, because I realised my user interface was pretty plain and ugly, and not very customisable. I discovered WPF, and my design improved drastically.
Planning, I have now realised, is essential. As tempting it is to get ‘stuck in’ and start programming straight away, especially being the only person working on the project, it ends up being a hindrance in the long run. I realise now that my implementation and testing phases would have definitely been shorter had I stopped and been more disciplined in my method.
Programming is Hard Work
Programming is difficult. That is not to say that it isn’t enjoyable, on the contrary — the challenge is what I love about programming. Breaking down a problem into its constituent parts, and building a solution to solve that problem. It is what programmers do; it is what I love.
However, it does take a toll on you, physically and mentally. Working on a project every day for months on end was definitely a struggle, especially if you are stuck on one issue for a whole day. This, combined with the fact that I was learning a whole programming language, did cause some strain.
At times it is frustrating. Never have I bashed my fist on my desk in frustration, until starting this project. Numerous times I had considered giving up, after spending countless hours completely stuck.
But this too shall pass.
And it is so worth it.
Programming is Rewarding
The reason I find programming so rewarding is that feeling when, after all the time and effort you put into a problem, you complete it, and all of your tests pass.
Or the moment when you are wake up in the middle of the night to the solution to a problem you had been having all day; the click you feel in your brain. The feeling of absolute lucidity.
And, when you finally wrap up a project that you have been working on for over a year.
The Best Way to Learn Something Is Practically
Now: I hate the phrase ‘practice makes perfect’; it is trite and obvious. But, it is hard to deny the fact that practice is the key to learning a skill, especially when it comes to programming.
Having worked with C# and the .NET framework for over a year, I can say that I am very comfortable with them. I’m no expert by any means, but I have a very good working knowledge of the two now.
Looking back on my code from months and years ago gives me an interesting perspective. It reminds me that there is so much more to learn; that my skill now should improve drastically in the years to come; that things that I struggle with now will soon become second nature. One thing that has always daunted me in the future is getting a full-time job in programming or software engineering. Now, that prospect excites me; the fact that I will be able to do what I love as a career, and the amount that I will learn at the same time… That is something to look forward to.
Things Take a Lot Longer Than You Expect
Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
— Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
Hofstadter’s law is ubiquitous in the programming industry, and my case was not an exception. What I thought would take up to six months, ended up taking thirteen. This caused some grief, because I had expected to finish before I started university, but I ended up working until the start of my second semester.
This had two consequences: firstly, I did a lot more work than I had expected. Secondly, it made me fully grasp the amount of time it requires to build and test a full system; doing this alone was certainly a challenge.
This only made the feeling of completing it that much sweeter.
Testing is Time Consuming
If debugging is the process of removing bugs, then programming must be the process of putting them in.
— Edgar W. Dijkstra
Beware of bugs in the above code; I have only proved it correct, not tried it.
— Donald Knuth
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
— Brian W. Kernighan
Yes, debugging. The bane of every programmer since the conception of programming itself. There are countless quotes that can be used to summarise it; I had certainly underestimated the importance of debugging, and how much time I would spend doing it.
And the hellish pain it would inflict on me.
Picture this: eight months ago, in June, I was in a dark, gloomy place. The material calculations, upon which all of the pricing calculations for tube quotations are based, were outputting the wrong values. A whole month of torture, trying to debug the relatively complex calculations. It was the core of the pricing system, and it was failing.
The fix, as is always the case, was a simple one. It was a single character in one of the functions: I had written ‘<’, instead of ‘<=’. A single character was missing. One character. Anybody who has ever tried to debug a relatively large project would understand the misery this causes.
Even after the software was deployed to the company’s server, bugs were appearing. It is one thing to run a couple of test cases on your program. It is another thing for multiple employees to use the program, all day.
The cycle of suffering goes like this:
1. User reports a bug
2. I fix the bug
3. I upload the fixed version
4. Go to Step 1
This repeats until one of two conditions is met: either everything that can go wrong has gone wrong, or “until the last user is dead” (Sidney Markowitz, 1995).
To summarise, testing is the worst and it takes more time than you would expect.
And that’s putting it lightly.
A lot of the pain and suffering I went through debugging was self-inflicted; that is to say that 90% of the bugs I came across were caused by sloppiness and carelessness.
While my programming technique has improved drastically, I still overlook things that I shouldn’t, and this eventually ends up biting me in the arse.
Be rigorous, be conscientious. Don’t take shortcuts.
How to Program Properly
Looking back to a year ago, and further even, it is eye-opening to see how much my programming technique has improved. What would once take me a couple of hours to create, I can easily do within a number of minutes. Admittedly, I was pretty new to the world of programming, and I still am, but the fact that I know ‘what I’m doing’ (sort of) is something that gives me pride.
And, well, if you don’t know something, just Google it.
StackOverflow is Your Friend
This Is What I Want to Do
If I had to describe this experience in a word, it would say ‘eye-opening’, in more ways than one. I feel like I have just dove off the 5 metre diving platform, and now I’m itching to dive off the 10 metre. The most important thing I will take away from this project is that I am now certain that this is what I want to do with the rest of my life. It has given me the confidence and motivation to pursue this path.
I have the taste for it and I’m eager to continue.