How to code faster?

Quote:

Original post by Tubos Hi! I found that there is a HUGE difference when I'm totally focused vs. when my mind is jumbled. I can code MUCH faster when I manage to think about nothing else than the software. Do you have any tips how to achieve that state more often? I read Mihaly Csikszentmihalyi's "Flow", but I'll appreciate some ideas as related to computer programming :-)

i have the same problem but my one is stranger! before i start doing some coding, i basically play a few games of chess with the computer (to wake up my brain cells i guess) and i can basically destroy ratings up to 2000 in grand master, about 3000 is max rating. yet sometimes after i have finished playing chess and start coding my brain just "refuses" to think, it's like my brain has a brain of it's own lol! i would say an empty stomach and boredom can affect learning in a bad way.

you might wanna try meditating before programming!

I find the strongest correlation to coding well and not is the previous days sleep. So get enough sleep, don't eat after 8 and do a small exercise routine during the morning after waking up (jog or walk), I find that works well for me.

-ddn

A meaningful todo list with small, bite sized chunks. Sometimes it helps to almost finish a task before stopping and then finish the task tomorrow so you start the day off with an accomplishment.

Practice.


Eventually you can get to a point where you can drop into the zone at will. It's all about getting practice.

For me is food. Good breakfast can make diff. To ramp up the brain's processing capabilities, fuel is needed. Otherwise, the whole day will be a fuzzy mess, and wasted on mindless youtube sessions.

Quote:

Original post by GroZZleR A meaningful todo list with small, bite sized chunks. Sometimes it helps to almost finish a task before stopping and then finish the task tomorrow so you start the day off with an accomplishment.

This. I am using gToDo, though I began writing my own hyper minimalistic todo-list manager that feels like gToDo, but with some more feature and cross-platform.

Also, it helps a ton if you find your own perfect coding time. Mine is in the morning, often before labour.

The right music can help, too. I can totally get in flow when listening to some spacy idm-tunes, for instance.

Quote:

Original post by ddn3 I find the strongest correlation to coding well and not is the previous days sleep.

This. Applies to non-coding activities too.

Quote:

Original post by samoth Quote: Original post by ddn3 I find the strongest correlation to coding well and not is the previous days sleep. This. Applies to non-coding activities too.

Except for sleeping.

Quote:

Original post by phresnel Quote: Original post by samoth Quote: Original post by ddn3 I find the strongest correlation to coding well and not is the previous days sleep. This. Applies to non-coding activities too. Except for sleeping.

Or falling down stairs.

I fall down stairs way better when I've had less sleep.

Quote:

Original post by phresnel The right music can help, too. I can totally get in flow when listening to some spacy idm-tunes, for instance.

Seconded. Something about IDM and programming... it's like peanut butter and jelly. Autechre may be a good start for those interested.

I code a lot faster when I stop thinking. The problem with that should be pretty obvious but when I'm coding something that's pretty intuitive for me in the first place, it's the most efficient thing to do.

Did any of that make sense or did I write it too fast?

I'm sure a lot of people will start mentioning programming methodologies (Agile programming, TDD, GTD, etc.) to answer this question, but my point is vastly more simple.

Plan it all out ahead of time. Your brain can't focus on planning out your program and also writing clean, efficent and quick code. It's one of my favorite sayings that 15 minutes of planning before you sit down at an IDE will save you hours and hours of debugging, refactoring and basically a huge headache later.

Hope this helped a little, good luck!

I have a stopwtch on the desktop that countdowns 60minutes
forcing myself to stay at the PC for that amount of time is a great way of achieving stuff.
I love deadlines

Quote:

Original post by coderx75 Seconded. Something about IDM and programming... it's like peanut butter and jelly. Autechre may be a good start for those interested.

IDM-er here too. I usually listen to mixes. You can find a couple of good ones here.

The mind might need a moment to switch context to coding, after doing other stuff. So an easy way is to plan an initial hour of slow coding before expecting to having switched to total focus on the code.

In other words, if you want to code fast for one hour, plan to sit down for two hours of which the second is the fast one.

So weird no one mentioned coffee..??

Quote:

Original post by Code_Dark Plan it all out ahead of time. Your brain can't focus on planning out your program and also writing clean, efficent and quick code. It's one of my favorite sayings that 15 minutes of planning before you sit down at an IDE will save you hours and hours of debugging, refactoring and basically a huge headache later.

There's an old programming proverb: The sooner you start coding your program, the longer it's going to take.

This has definitely been my experience.

Many of these things were touched upon by other posters, but here's a couple suggestions from my personal experiences of doing professional software development for over a decade.

• Minimize interruptions. Turn off email notifications, IM, IRC, cell phone, desk phone, television, radio, music with vocals, etc. In the real world, we can't do that all the time, but at least set away some time without interruptions.


• Keep a list of features/requirements for your project. Break that list into small coding tasks. Each task item should be something that would take less than an hour to do. If it takes more than that, then you need to break that task into smaller tasks.


• Have a clear objective before you dive into coding. Ask yourself what do you want to get done in the next hour? Be specific. Pick one or more items from your task list. Can it be done now? If not, revise your task list first, until you can pick something that will fit in the time allotted. If you are creating something that will depend on code that does not yet exist, you need to factor in time to create a stub classes/procedures for those dependencies. Don't get caught up in coding the functionality for the stubs. Add them to your task list instead.


• Use source control for even the smallest projects. You'll be surprised how many times you'll come to point where you'll wish you had access to the original code you just started revising an hour ago.


• Don't reinvent the wheel. Use standard and third party libraries if possible. And don't write code that you don't need. If the code you're writing doesn't accomplish the objective of the task(s) you chose for your coding session, stop; ask why you are writing this and put it on your task list if it is necessary. Discard the code or place it on the sidelines and focus back on the task(s) you chose. Remember, the fastest code you can write is the code that you don't write.


• Know your tools. Know your IDE and your compiler. Know your standard library. Look at third party tools, especially tools dedicated to code refactoring. Using the appropriate tool(s) for the job is critical to keeping your workflow running smoothly and saving your sanity. The wrong tool will make the code either more difficult to implement, or more difficult to maintain, or even both.


• Stay up to date on the latest best practices. But remember to only use them when they apply to your situation. Don't fall into the trap of rewriting something just because the way you wrote it was the old way of doing it. If there isn't anything wrong with the code, don't touch it.
  


• Don't beat yourself up if you don't accomplish what you set out to do in the the allotted time. Underestimating is perfectly natural and by allocating specific chunks of time to a problem, it allows you to understand the problem better. Again, breaking things down into discrete tasks are critical to both understanding the problem and implementing a solution. It allows you to focus. But it takes time and practice to get the proper granularity for the things you're trying to accomplish.
  


• Read David Allen's Getting Things Done. It's not a book on software development, but I found the principles he describes fit very well with developing software.