A lot of the things I do to work faster are things to do before you start coding:
- Setup version control for your source code, both remote and local, so you can quickly revert mistakes or commit and push through to the remote for backup and eventual migration to the site. If you can afford a private repo on GitHub, it's a good choice combined with a local git repo cloned from GitHub.
- Setup a ticket system so you can track requests and their progress (GitHub is also good for this).
- Use ticket numbers in your commit messages to simplify cross-referencing tickets and changes.
- Configure your site so you can migrate code via your remote version control. There are many different ways to do this, but generally you're going to want to work in a "develop" branch and use a "master" branch to migrate changes to the site. You can use a very basic setup by cloning and pulling from the server or use any number of tools to make the process as complex as you feel is necessary to cover your migration needs.
- Setup your local and remote databases, including test data on your local (if you're at a point where you can do that), and setup your client application with the ability to connect to both databases (i.e. MySQL Workbench if you're using MySQL, generally I configure it to prompt for the password when it connects and use different passwords for each server, so I always have that reinforcement when I'm connecting to a server other than my local dev server).
- Setup your development server with virtual hosts, in case you need to test different configurations or work on multiple sites.
- Configure your editor however you want it for the way you work.
- Setup VMs to test your site in whatever versions of IE you need to support (modern.ie is a site run by Microsoft which supplies pre-built VMs for this purpose).
- Once you have everything setup the way you like it, create an image of your development environment and each server, and put them somewhere safe. Create new images each time you make major configuration changes or major changes to the software on any environment.
On the development machine, I also recommend using as many cross-platform tools as possible. You don't want to change your tools just because you have to change your OS.
During development, set aside some time for periodic code reviews and refactoring. Sometimes you don't realize you're writing the same code over and over again until you come back and look at it without looking for something specific that needs to be fixed/worked on.
If you're going to refactor some code, create tests (if you didn't before), or, at the very least, write up the expected behavior so you can manually test the code. Benchmark the code using a debugger (like XDebug's profiler) so you have some performance statistics to check against when you've finished refactoring (and run the benchmarks multiple times so you can get a range of numbers, rather than a single value which may be exceptionally good or bad). Then you can refactor, compare the performance, and test the code to make sure you didn't break something. If there's a degradation in performance, you're going to have to determine whether that's worth any extra time you would spend writing the same code over and over again (or the maintenance headache if you have to change something in code that's duplicated all over the place). If there's an improvement in performance, you'll be glad you made the change, and probably a little worried that you missed something in your testing that required the extra time.
Some people feel the code reviews and refactoring are themselves a waste of time, or maintaining tickets is a waste of time. In the long term, they're adding some overhead to the process, but they ultimately save time if you use them as tools and part of your process, rather than tacking them on as an afterthought. When someone asks why a change was made, I can find the change in version control and look up the ticket. When someone asks me to do something, I open a ticket, even (or especially) if it's something I don't plan to do right away, so it's there as a reminder. If I move a method into MY_Controller and don't have to re-create that method in 5 controllers, I've saved some time. If I then have to modify that method, I don't have to remember which 5 controllers implemented it and modify all 5 of them (or track down the same bug 5 times), and I've saved more time.
