If you are a professional programer in 2016, you very likely are familiar with the term "refactoring". This term was placed in our vernacular by the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler [1]. In the Preface to the book, Folwer writes:
Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy .. ... I must admit to some bias here. I was that consultant. Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance. The consultant Kent Beck was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring. The success of this project, and role refactoring played in this success, is what inspired me to write this book, so that I could pass on the knowledge that Kent and others have learned in using refactoring to improve the quality of software. ... In this book I describe the fruit of a lot of research done by others. The last chapters are guest chapters by some of these people. .... I've left the final word, Chapter 15, to the master of the art, Kent Beck. TL;DR - pay heed to the history of your profession.
[1]: https://www.amazon.com/Refactoring-Improving-Design-Existing...
At least not since this was published:
http://www.amazon.com/Refactoring-Improving-Design-Existing-...
Martin Fowler really struck a chord all the developers trying to do the right thing by cleaning up badly structured code, by giving the practice a name and explaining why it's important. Refactoring is definitely a widely acknowledged and accepted practice today, although probably more so in some communities than others.
Calling it refactoring dates back to at least the early 90s[1], which I'm pretty sure predates "hipster hackers." If anyone "made it cool" it was probably Martin Fowler[2].
Refactoring is when you rework a specific section of code, usually that you're about to work on, or just worked on, to be cleaner. It's a long-term approach, and it's how large applications stay maintainable over the long term. For your specific example, you'd leave your app alone. You wouldn't rewrite it, or touch it, until you find a bug, or need to add a new feature, and then you'd rework anything you need to to add the feature cleanly.
On a related note, Refactoring by Martin Fowler is a great book, and I'd recommend everybody pick up a copy. It's a beautiful hardcover and looks great on a shelf, too.
http://www.amazon.com/Refactoring-Improving-Design-Existing-...
Rinse repeat. You'll find that once you have one language down, the process will go much faster with the second. The features and syntax of most languages are pretty similar.
You can pick any language you like to start with, but personally I'd recommend starting with a hard typed compiled language rather than a dynamic language. Dynamic languages are easy to learn, but its easy to be a lazy and bad programmer in them. They let you get away with too much. Hard typed compiled languages are a) much better at catching your errors and b) much harder to be a lazy programmer in. They don't let you get away with things nearly as much.
I'd recommend Java, seems to be the language a lot of people start with. It will also give you a good founding in open source programming. I started with C/C++ and I'm glad I did. But that was more of a challenge - had to learn pointers and memory management in my first language. And after that I took a little while to learn the open source mindset, since I'd started in a procedural language.
Once you have a good grasp of an object oriented language like Java (or Python) and what object oriented programming means, then I'd recommend reading the Gang of Four book on Design Patterns (http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje...) and Martin Fowler's book on Refactoring (http://www.amazon.com/Refactoring-Improving-Design-Existing-...). Those will give you a pretty good basis in software design and maintenance.
In terms of recommended reading for learning a language, the O'Reilly books are nearly always good in my experience. Here's one for Java (Learning Java: http://www.amazon.com/Learning-Java-Patrick-Niemeyer/dp/0596...) and here's one for Python (Learning Python: http://www.amazon.com/Learning-Python-Powerful-Object-Orient...)
You will simultaneously learn:
- terminology and models relevant to software design and construction at every level
- principles of good coding and how to tell good code from bad
- the ability to redesign code as needed
- the experience and knowledge necessary to approach coding with confidence
All of these are the most critical tools you need to transform yourself from someone who sorta-kinda knows a few principles of coding to someone who groks software construction.
If I had to choose between a co-worker who truly groked the principles of re-factoring and a co-worker who had a PhD in Computer Science I would choose the former every time. It's really that important.
https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...
https://www.amazon.com/Refactoring-Improving-Design-Existing...
EDIT: And it appears the website is a direct rip-off of these books.