

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?<p>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?<p>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

