What are some work habits of successful programmers? I feel like my work style is very ad-hoc. Some days I'm in the zone and can churn away, and some days it feels like I just bounce between searching docs and checking hacker news. I think I'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're working on and avoid distraction? |
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.
(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.
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.
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.
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.
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.