Ask HN: Do you have any (little known) tricks to code faster?
Other than the usual steps like planning well, doing one thing at a time (not multitasking) etc - are there any tricks that you use to code faster? I'm asking because I am working on a big, slow, legacy code base and am coding twice slower than my usual speed and it is frustrating.
4 comments
I've had to work with a big, slow legacy ball of spaghetti several times in my career. The original coders were long gone, but the code lived on.
I always found the best approach was to get familiar with the code as quickly as possible: read it beginning to end. Then disrupt it with small changes to see what happens. Insert comments as needed. Refactor here and there to make it easier to understand, and rename functions and variables to more meaningful names as you come to understand them. I've found it useful at times to print out all the code and lay it out on a table.
Eventually you become the master of the code. It's painful and you may have to put in some long days, but it's worth it.
Of course, the whole time you're working on this project, you might be thinking of ways to replace it with something more modern, performant, and maintainable.
I always found the best approach was to get familiar with the code as quickly as possible: read it beginning to end. Then disrupt it with small changes to see what happens. Insert comments as needed. Refactor here and there to make it easier to understand, and rename functions and variables to more meaningful names as you come to understand them. I've found it useful at times to print out all the code and lay it out on a table.
Eventually you become the master of the code. It's painful and you may have to put in some long days, but it's worth it.
Of course, the whole time you're working on this project, you might be thinking of ways to replace it with something more modern, performant, and maintainable.
The book Working With Legacy Code is fantastic and suggests something a lot like the approach you've outlined. I leaned on it as a source of ideas when I once took over a fairly challenging old project. The other thing it recommends is adding tests but really all the parts you talked about are as important if not more so.
To OP, I'm repeating some of what blisterpeanuts said but it's worth emphasizing that refactoring, even with very small changes, will make a huge difference over time. It gets you engaged with the code, helps you know it, and gives you small things to do when the big picture is too overwhelming.
Also as he said, renaming variables as appropriate.. sounds minor, but this is huge, because you can make the names things that make sense and make the code more readable.
The small changes you'll make will add up and the code will become easier to work with, and then the work will go faster.
To OP, I'm repeating some of what blisterpeanuts said but it's worth emphasizing that refactoring, even with very small changes, will make a huge difference over time. It gets you engaged with the code, helps you know it, and gives you small things to do when the big picture is too overwhelming.
Also as he said, renaming variables as appropriate.. sounds minor, but this is huge, because you can make the names things that make sense and make the code more readable.
The small changes you'll make will add up and the code will become easier to work with, and then the work will go faster.
#1: Close my HN tab
You need to figure out why you arw coding slower. Is it because you don't know the code base? Is the code base terrible?
Old codebase, not well written, no documentation. Also it is slow, so if I make a change, it takes 15 seconds to just load the page, sometimes 30-45 seconds depending on the page.
There isn't much you can do, besides slowly re-writing the codebase until you get to the point where new changes don‘t take as long.