Everyone (ok, every developer) has had that first day on a running project and has gotten excited about diving into that fresh code, eager to leave his mark and contribution on it, only to get hopelessly frustrated and lost trying to figure out exactly what and where is everything. That is the "joy" of working with legacy code.
Most of the times it's not that the previous developers didn't know how to code. You may even have a perfectly functional platform, proving someone did know what they were doing, for the user or client, that is.
That is why we at Cloudoki believe that the quality of the code and documentation (yes!) left behind is as important as the functionality itself.
It's working, how can it be so bad?
Having a working project is indeed the main goal, but having a functional platform with a chaotic code is like having an awesome car with a full deposit that can't be refilled without the need to tear the car apart. It works for driving, not for maintaining.
We have the prefect notion that no code will remain unchanged and no product will stay static for long. New technologies pop-up every day and things need to be kept up to date with the new and exciting toys. Guess what, that is a good thing. It's the reason we get excited about doing what we do, and why everyone still has a job.
If your code needs to be remade every time one needs to update it or hook it up with some new awesome feature, it's not made to last.
The Junior profile mindset
It's not always easy to figure out the best practices while developing a certain project. Sure there are many well known practices any developer should follow, but if you take into account the amount of programming styles, languages, design patters etc, it's easy to get overwhelmed and not really figure out what's the best way to do something. This is why at our core we use the junior profile mindset as rule of thumb.
This mindset is basically just trying to put yourself in the role of a junior guy that is handed your piece of code, and figure out if he could find his way around it. You may feel tempted to think that he obviously wouldn't because he is a junior, and this is somewhat true in the sense that he may not know the syntax or have any experience on what you are doing, however, the goal is to deliver something that one can compare and match with existing documentation, patterns and well, common sense.
On the other hand if your code is yours alone, if it is not documented and follows no "intuitive" logic other than your own, even a Senior developer will have trouble finding it's way around it. You do not want to upset a senior developer.
Develop structures and logics as familiar and broad as possible, document as much as you can, and make things as simple as humanly possible. In programming less is indeed more, and you should always keep it simple.
Why code like it's the last day?
Every single basic tutorial about programming mentions the necessity of keeping it clean, simple and documented. However, we indulge.
Thinking like everyday is going to be the last day and act on it will definitely prevent you from taking wrong, complicated turns along the way, before it's too late.
We all feel the urge to "clean and document it later" but common, we are not fooling anyone...