
Error in code. Happens a lot to us!
This is a long write-up. If you get bored at some point, I recommend going to the conslusion.
Writing new code. Fixing old code (that’s like archaeology, right?). But which one of those does help you become better faster?
More than two and a half years I’ve been fixing code that has been written by all sorts of programmers. The code ranges from PHP3 and IE6-only to PHP5 OO. I’ve been deploying these apps to all sorts of servers and have seen a lot of compatibility problems between OSes, PHP versions and web server configurations. So I think I have something to say about this.
My other one and a half years I’ve been writing apps in teams or alone. Doing freelance jobs. This time I could choose myself which patterns to use, OOP or functional programming to focus on, and so on.
Debugging, fixing, enhancing
Bad code – this one you can not evade. At some point we all did code worse than we do now, and this probably will have to be fixed by someone. What’s good about bad code is that you can identify it and think of how to make it better. But if you are not experienced enough this can be a pitfall and you would “learn” from it. Bad habits are hard to loose…
Debugging – finding that one buggy line in a mist of files, functions and classes. Maybe the culprit is a misused function? For example:
1
2
3
4
5
6
7
8
| <?php
// Let's say the outputted email list is not unique. The code is this:
$list = get_email_list($params);
array_unique($list);
output($list);
// If you're not familiar with array_unique(), this can be hard.
// Line 4 is buggy and should be like this:
$list = array_unique($list); |
The good thing about debugging is that you get good at finding problems. You learn to follow the traces, use xdebug. You are angry at bad coders – there is a chance that you will have to fix their code! You get sharp at giving suggestions how to find problems. If you are working on well written projects, debugging can be a good source for looking at how things should be done.
But in reality, debugging good code is rare. If you’re at it – be happy.
The drawback of debugging is that you seem slow. And you think this too. It is hard to read other programmer’s code, even more if it’s crappy and standard-avoiding. Or you are debugging a software that is buggy not in code, but in logic. And you don’t understand how to synthesize these atoms, even when you have a 600-page long manual to help you…
Other good things I’ve learned when debugging:
- Code quality matters. Choose a coding standard and stick to it. You’ll say thanks to yourself later – and others will see that you have quality.
- At some point you quickly can say what code is good and what – bad. Why isi t bad? This requires more experience, but you are on the right track!
- When facing problems you have good examples of BAD code to support your position.
etc.
Optimizing – this is one of the key parts in real-life application work. Optimizing databases, code, UI (usability or JavaScript speed), etc. But be careful -Optimization is root of all evil. This is often learned the hard way. On the other hand, if you like programming, you will like writing the best code there can be. Remember – this is probably impossible (Cite: “If you look at your code a year later and won’t find anything to rewrite, you are not evolving”) so take the time needed to finish your job in consideration.
I like optimizing! Next week I’ll have a jQuery optimization study on one of my work’s projects – I’m looking forward to that!
Writing new code
This part is more interesting for every programmer. This is the one and only way you can be the God of Dev, Michael Jordan of your keyboard.
When writing new code, you are swallowing information faster. You are forced to find solutions to problems you’ve never faced before. You can choose the best pattern that you know of – or learn a new better one. The choice is yours.
But at the same time writing new this requires more skill and experience. Most programmers have their own vision of “the best path to glory”. And this can be wrong. Very wrong.
Speed
When programming your own brand new shiny stuff, you can measure your programming speed, e.g.
$speed_factor = ($job_done_hours + $error_fixing_hours) / $estimated_hours;
if ($speed_factor < 1)
$manager->kickAss($you);
else
$manager->makeWorkMore($you);
Compared to debugging, this time you can measure your speed. You can get faster by analyzing the parts you’ve got stuck and finding on how to not get stuck again.
After a year of write-everything-yourself you are starting to realize that using third-parity libs is a time-saver. And a life-saver in terms of open-source (or paid software) support and bug fixing.
Experience
When working on something, you are gaining experience. Once you use a wrong pattern, next time you will try to use a better one. You are learning hands-on new techniques, writing all sorts of tests, mock-objects, and so forth.
In some time you start understanding that hacking the core of the framework you use was a bad idea. And why.
After writing a million or two lines of code you will start getting good at defining the time needed to complete a task. This, of course, will be quite theoretical, but still in the range of “good”.
In the time you code new stuff, you will learn frameworks (server- and client-side), patterns, libraries. You will do more debugging and fixing but this time of your own code.
Conclusion
In my opinion, you need the experience of fixing and writing code. Yes, writing new and fresh code does let you evolve faster, so you should write new stuff more. But it teaches you some good practices “the hard way” – by making and fixing errors. Sometimes it is better to get familiar with bad code of others so you can learn what’s bad. But you have to have a good eye for that.
What’s the most important is the people you work with. If their level of experience is lower then yours, you will have to push them and this will slow you down. But if your co-workers are brilliant people, real problem-solvers and deep into programming, no matter what you do – debug, code or just listen when they talk – you will go up.
I haven’t mentioned this in my article but it is the truth. This truth can be sad because if you’re working hard all alone, you’re doing great as a programmer, but in team of great people you would be moving a lot faster. So go and find a job that does not only offer a good pay for your skills but also has great people that you can learn from.
I wish you that you would one day be a programmer that others look up to. I am striving to be one like that.