
What are some work habits of successful programmers? - heathkit
I feel like my work style is very ad-hoc. Some days I&#x27;m in the zone and can churn away, and some days it feels like I just bounce between searching docs and checking hacker news.<p>I think I&#x27;d be more productive if I were more methodical in my approach to work. How do you guys organize your day? How do you keep track of what you&#x27;re working on and avoid distraction?
======
freedevbootcamp
Things I've changed to be a better programmer.

1\. I used to be up all night long working on my side projects, sometimes till
5am. Then go to work on two hours sleep.

Now I go to bed at 9pm and get up at 3am for three hours of very productive
coding. Fully focused three hours of coding.

2\. I would always be looking for new ideas, new tools, new workflows and say
yeah Ill do that next week, never happened.

Now I have a todo.txt list that I document everything and follow it every
morning.

I have a todo.txt list, weekly.txt of what I have completed and a blog.txt
that is a personal journal of my monthly accomplishments.

3\. Never work on your personal projects after doing CRUD applications all
day.

When I get home from work I relax as much as possible before 9pm bedtime. I
try to think about my personal projects and what Im going to do next to
improve or refactor before moving onto the next feature.

------
jtlienwis
Do a Google search on "spider webs on caffeine". Over my long career as a
programmer, I went from looking at caffeinated beverages as an aid to getting
things done, to the discovery that I made far more programming errors under
the influence of caffeine. I cut out my addiction to coke and pepsi and
watched my productivity soar. Now, a new successful software company near my
home town has built a new building, and the newspaper account describes the
office spaces that have free access to Monster type drinks etc. I just wonder
how this myth of "programming fluids" for programmers got started and why no
one has actually studied it.

~~~
jasonm23
Years ago, when Jolt Cola was released, the media trope of caffeinated
programming fuels began in earnest. Of course this was subsequently bolstered
by naming two popular programming languages Java and JavaScript in the 1990s.

(Java, for the uninitiated is a common word for coffee.)

The naming of Cocoa, was also a sarcastic pun on the whole Coffee thing.

We had CoffeeScript a few years ago...

Anyway it's cues like this which help prop up them meme of Coffee/Caffeine ==
programmer fuel. With that sort of cultural baggage it's neither here nor
there whether there's been any studies...

It's simply lore, and holds about as much validity as the beard length gag.

------
angersock
I don't know if I count as a "successful" programmer (I'd like to think so),
but here are things I've started doing in the last few years that have had a
tangible increase in my productivity.

 _Know yourself_. Know your body and your mind and your tics. If I don't get 8
hours of sleep, for example, I get irritable and have trouble focusing. I've
had arguments with managers and executives about this before, and frankly I'll
quit before I'll commit to working at not my best. Having my ass in the chair
at 9 sharp, tired and bleary and cranky, does nobody any good--especially if
waiting a mere hour would result in like 4x the productivity. If your bosses
can't see this, and you can't show them numerically that you are producing,
you need to leave your job. Speaking of showing progress...

 _Make todo lists_. Whether in an issue tracker, post-its, notebook, or mad
scrawlings on your cube wall, make notes of the next few things you need to
get done. Annotate those things with the mid-to-low level deliverables or
requirements. This is not just to keep track of where everything is, but also
to help you get right back into context when you need to switch gears.
Moreover, this also helps you audit what you've been _doing_ the last few
months.

 _Write sloppy solutions first_. Don't lose steam fighting optimizations,
unless that is the exact goal you're trying to accomplish. Welders use tack
welds (teeny welds that are fast) to shape up a workpiece before going to do
everything--similarly, use the obvious solutions (preferably functional ones
if the language, like JS, affords them) and then go back and clean things up
in a subsequent pass.

 _Accept that you 'll waste time_. I know that some amount of random garbage
(chats, twitter, HN, etc.) is useful for helping reset my brain. On bad days,
it even gives me a place to vent while I'm waiting on solving problems and
gives me a sense of community. Don't begrudge yourself this, and instead focus
on learning to recognize when you've gotten that recharge and can go back at
things.

 _Do the medium-detail design work up front, and write it down_. Especially at
hackathons or during stressful times or even when just spewing code because
you're not on the ball, it's really easy to code yourself into corners. So,
the design work is a guardrail to help nudge you onto the right path. This way
you won't get into a situation where you have to throw away a lot of work.

EDIT:

One more thing.

The measure of a good engineer isn't how awesome they are when they're at
their best--it's what and how consistently they can deliver when they're not.

~~~
mathgeek
>Make todo lists

I think you missed one important point of this, for my workflow anyway: it
helps you to look at the list after completing it and feel a sense of
accomplishment when you otherwise feel like you haven't accomplished anything.

For people who suffer from depression, are somewhat bipolar, etc., this is
huge.

~~~
angersock
Excellent point!

------
nyrulez
Great advice all around.

Some advice that may not be obvious:

Keep extensive notes about stuff that you refer to repeatedly. This may
include code snippets, test examples, shell commandlines, and so on. Over
time, a good programmer can accumulate their own library of stuff that helps
them execute effectively.

Meditate for at least 5 mins. Self explanatory. Productivity is directly
proportional to your ability to manage distractions. Meditation is an
effective tool.

Pace yourself. Just like in a marathon, you keep a steady non peak pace, it
can be useful to allow yourself some patience (vs being hurried all day) ,
take some breaks, and take a few deep breaths here and there in your schedule,
to let your mind reduce hyper activity and let it be more centered.

Have a good learn list. When you got some spare time, you can refer to it to
learn something in your field... Remember knowledge is a key component to
productivity.

------
jasonm23
# Write tests first.

You're going to write all sorts of little throw away calculations and trace
outs, and breakpoint, so just accept that:

1\. Test first is like a todo list item, but without the ambiguity

2\. You'll love that you have test coverage when you break something (or more
likely just avoided breaking something.)

I'm not going to say anything more about that, TDD can be just as cultish
(often of the cargo-cult variety.) as anything. Just think of it as a way to
solidify the spec of the next slice of code you need to fry up.

# Don't be afraid of terminals or cli's

Additionally learn how to use bash/zsh (include Readline line editor)

# Use a deeply programmable editor

Maybe it's the one which does modal editing (vim) or the other one with
elaborate key chords (Emacs) or whatever floats your boat (Sublime?! oh you
kids!) but, make sure you can extend it on the fly, to make it take the
repetition out of your work.

It will grow, it will become yours. Later you'll switch to the better one,
you'll know which one it is when you get there. If you're smart you'll realise
IDEs suck. (and sometimes you have no choice but to use one!)

# learn deep, then learn broad.

Much of what we know about one platform/language/machine/domain is applicable
across many others. When you're starting out, learn whatever happens to be the
main (platform/language/machine/domain) you're focussed on.

Later pick up experience with different (platform/language/machine/domain)s
and you'll find many similarities. You'll also find many enlightening
differences, which will bolster your knowledge of the
(platform/language/machine/domain)s you already know.

In effect always be learning.

# drill

As much as possible, always exercise your skills. You should try to tackle
problems just a little harder than you think you can solve...

You always have time to solve it, and once you have, you'll be ready to solve
something harder.

------
duncan_bayne
org-mode (or, I guess, any suitably feature rich note-taking-and-todo-list-
system). Anything that doesn't need immediate attention gets a note in an .org
file, for follow up later. I have a very limited stack depth when working, and
this approach keeps me free to focus on what I'm trying to achieve. Just one
tip - schedule time each day to review your agenda, or stuff you punt to a
list will never actually get done :-)

------
rsunder
1\. To-Do Lists 2\. Scheduled breaks for mandatory distractions to see the
outside world. 3\. Checklist of what went wrong - way to keep the learnings

