Ask HN: Programming More Efficiently?
I'm wondering if any more seasoned developers have good advice for me, as far as improving my workflow, and coding more efficiently? I use Vim, and am trying to improve my muscle memory for operating on code. Any vim user tips? At what intervals should I take breaks from coding? Should I stay away from developing on the weekends to let my mind rest? Should I keep working on weekends to keep my brain active? At times I have to switch projects and work on something completely different, sometimes even in a different language, and that seems to throw my mind of for a few minutes. Is there anything I can do to make the process of switching projects easier? Is it normal to be thrown off by an abrupt project-switch? Sometimes I have to do 2 or 3 projects concurrently, and I end up having 2 or 3 bash windows open with different projects in each one. Should I try to just work on one thing at a time?
Thanks for any advice, I'm just trying to improve my developing habits and consolidate my workflow into something that's as efficient as possible. Any advice from seasoned developers would be awesome!
8 comments
[ 3.2 ms ] story [ 32.3 ms ] threadI would definitely suggest working on one thing at a time. If you have multiple projects, just timebox them. 3 hrs working on project A, 3hrs working on project B (or 1 day working on project A, 1 day working on project B, etc).
Sometimes I'll get pulled onto different tasks abruptly and I don't really have a choice of when I get to switch, it usually happens only four or five times a day, so it's not a huge problem but it does interrupt the blocks of time I try to spend on other larger projects. I'm just wondering if there's any way to make the process of switching between projects easier?
For example, when I get started on a project, I normally sit down at my computer and surf the internet for maybe 20 minutes and play around in the command line. This "down-time" helps me get into the flow of things. Plus I normally try to avoid tight-deadlines so I don't really care if I spend 20 minutes dinking around on Hacker News.
If you have a similar work-pattern, maybe those 20 minutes could be spent instead reviewing a README.md or working on a Trello board, or adding new links to an internal wiki you've set up for the project.
I've found that touching the documentation that I've created really helps me snap back into a project since I can see exactly where I left off. And if I don't know what to do, I work on planning out the project.
Also, if all of a sudden I have a great idea of what to do, I'll spend half and hour or so making files and directories and writing the code entirely in comments. Then, when I come back to the project, it's only a matter of replacing the comments with real code.
Edited to add: and learn your way around copen, cbuffer, cnext, cprev
- try to recognize code structures that you are typing repeatedly across projects, and see if you can make snippets that reduce the number of keystrokes and time needed
- if you are performing the same action multiple times, try making a macro
- get familiar with the keyboard shortcuts for your editor of choice. Try to do as much without the mouse as possible
- for whatever editor you use, do a bit of research to figure out what good plugins there are that might help you. for example, if you write a lot of HTML, you could benefit from the emmet plugin (zen coding).
- try out a lot of apps. If you think "there should be an easier way to do this", then there probably is.
- avoid shortcuts that sacrifice quality for convenience. doing something quick and dirty will often just create more work for you later.
- don't ever make mistakes. or, if thats not possible, have a plan for debugging.
Aside from that, the only thing left to do is to minimise your unproductive working habits. The whole 'Vim is faster' thing is just a distraction - people can be 'fast' in a million and one different setups - the point is that if you pick a particular setup, you should learn how to use it. Learn the shortcuts and the tools available. This is just common sense. You don't learn to drive through trial and error - you know what each action you make is going to do before you do it. Read the manual.
Personally, I find that the best all-round way to improve my code quality and efficiency is to read for pleasure. Whether it's books or blogs, it doesn't really matter much to me. I find that when I have been reading, I can think more clearly about problems. I can spot ways to abstract problems far more easily, and I can express my ideas more coherently. Additionally, talking through a problem helps me a lot. Even if I am just explaining the problem to somebody who is not contributing anything to the solution - the mere act of being forced to provide an explanation can often highlight the solution far more quickly than if I had just sat in silence trying to figure it out.
For me, the workflow is about minimising unproductive habits rather than improving efficiency. The real test is how quickly you can identify the solution to a problem - the task of actually writing the code is something that is left to individual tastes and preferences. In all things - think first, act later :)
Coding is all about the mental work, so if you can keep your mind sharp it is good. Get enough sleep and devote some time to learning new things that are beyond (more difficult than) the work that you do. Getting better is all about challenging yourself.