Ask HN: Programming More Efficiently?

[patrickocoffeyo]

I've been programming for a few years now, and I've written a lot of code, but there are times that I want to write quality code 2 or 3 times faster. I do my best to keep my workflow straightforward, eliminate distractions, and stay focused on my tasks, and I get quite a bit done each day but the more I can do, the better, right?

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!

[powatom]

The only reliably effective way to improve quality and reduce time is to practice. This does not mean, however, that you should burn yourself out. Apply common sense: don't do something that is making you hate doing it. Only do it when you can afford the time, and not at the expense of your sanity.

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 :)

[madlee]

Some general tips for improving workflow: - within a specific file/project, try to recognize places where you are retyping the same (or very similar) code blocks repeatedly. try to pull those out into a function to avoid redundant code and typing

- 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.

[ohyes]

I definitely block out my time for projects and work on one thing at a time for a day or two if I can. Task switching can be expensive, but if you have some state saved outside of your head/computer, it can help jog your mind when you want to come back to the task. So I keep a (paper) journal of things I'm working on.

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.

[dllthomas]

One thing that has helped me when moving back and forth between projects is to use screen (you may prefer tmux) to wrap up particular contexts, having my bashrc set things like my history file based on a single variable. Just keeping history from getting mixed up helps a lot, I find, but it also gives hooks for other bits of tweaking (aliases and such)

[gee_totes]

Is this question about programming more efficiently or managing your workload more efficiently?

I 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).

[patrickocoffeyo]

It's really a question about improving my workflow and improving my programming habits, in an effort to product quality code quickly.

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?

[gee_totes]

I would suggest taking copius notes and using writing documentation to get over the switch.

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.

[dllthomas]

As a vim user, I have found a lot of benefit pushing my compiling and tests into a form where I can run make from inside vim, and get errors in a format vim understands (filename:line: error).

Edited to add: and learn your way around copen, cbuffer, cnext, cprev