Forced Coding

forced-coding

update:
I've been off for a week after finishing a project and moving house, in that time this domain dropped and just prior to that appeared to get 20k+ reads which is a bit omg. Anyways many comments all over the net, and certainly on reddit (comments here) - and thus just to clarify, the entire content of this post is purely a note to myself, and to help me in those times when you can't get going in the morning or such like.. in no way am I suggesting you don't plan or do things properly whenever you can - this is literally just some ways of getting through the day. Thought I'd made that clear and most people got it ;)
end update:

This one is more for my own reference, but sharing anyways as it may help others. In numerous scenarios it is really hard to "get going" when you're trying to code, particularly under the following circumstances:

* You haven't started coding till late(r) in the day
* Emails, Blogs, Social networking have taken up more time than expected and/or distracted more than anticipated
* You've just completed a deliverable, milestone or task.
* You're tired!

All of these are virtually daily occurances in the coding world, and here are the methods I've used to get going again.. no particular order, just a list.

Under all circumstance, avoid planning!
Planning is one of those things you can't do unless you are all ready in the flow, whether this is because you've just had a client meeting, a long discussion, or read a full spec - it's not the thing to do to get your flow going, all you'll do is plan nothing, plan badly, or stare blankly at the screen / paper.

Don't read related material to get you in the flow.
This will purely serve to distract you, make you think about doing things differently, doublt what you've done or worse throw you in to planning mode - fact is you won't be planning "your" app though, you'll be planning "some" ideal app or scenario.

Pick the smallest task, whether complex or not, and just do it!
Doesn't matter what it is, so long as it's coding a little part of the app, or modifying part of it, then it'll do. It could be adding an extra field to an object or table, popping in some validation, anything small and simple. It really doesn't matter if you do it right or wrong; you're not doing it to sign off a task, you're doing it to re-aquaint yourself with your system, by the time you've been through X lines of code you'll be back in work mode and firing on all cylinders, well on your way to getting zoned.

Music, Headphones, Repeat.
You'll know the genre that suits you, personally I find repeating an album or even song fades me in to the zone and keeps me there. The repetitiveness of the tune keeps you there, because just as a phone call can distract you, so can a change in tune to something at a different tempo or worse a completely different genre.

Don't cram!
If you've only got 15 minutes before the next sizable interuption, forget it, don't do anything just chill - make a coffee, smoke, whatever. You're not wasting time you're saving your zone, you can only get zoned a couple of times a day, so don't get zoned for only 15 minutes - save it and get zoned for longer later on.

Speedcode
Why not? as nike say "just do it", if the code has 10 bugs but is finished in half the time then you've done good, that gives you loads of time to fix the bugs, and more importantly you get to those moments where you realise x,y&z need to be changed much quicker. Not only that, but would you rather have a week to go and have a list of 80 bugs, or a week to go and 2 major deliverables a week overdue..

Communicate for no reason.
Often a major focus is simply talking to somebody else on the same project as you, whether its the client or a workmate, and the more stressed they are the better, they'll not only blast you with things but their urgency / stress will often convey straight over to you and focus / zone you instantly.

Do the thing you know, not the thing you don't.
Inline with "don't plan" and "pick the smallest task", always pick something you can already do (if possible), as with everything else, the things you don't know are much easier when you're already zoned, not only that but you'll be more focussed when doing the thing you don't know so less likely to over spec / over code it.

Don't code other things!
nothing on earth will kill your project like working on something else, every minute you spend on another script or app is like an hour lost on what you should be doing, and with every minute that passes you're getting closer and closer to utter project failure - and hence why most open source projects are dead.

Remember, the key to forced coding is just to get you in the zone, and ultimately boils down to just getting stuck in there with some lines of code on your project.

Works for me anyways [most of the time] - if anybody has anything to add (constructive) then please do!

Regards - nathan

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Printed from: http://webr3.org/blog/general/forced-coding/ .
© Your Name Here 2010.

25 Comments   »

  • Great tips. I'm in a funk right now; I'm ready to try them out. Thanks.

  • nathan says:

    snap! that's why I wrote it, 6 deliverables and 2 days to do them!!

  • Nice piece of advice dude. I also do a lot of these things like picking off the smaller tasks first. Also gets you a better overview of what remains to be done, since 75% of tasks get done in 5% of the time.

    My main issue at the moment is that I work at the client ON LOCATION. This really kills my productivity. Advertising agencies are really noisy, sometimes like a big kindergarten with lots of noise. Gonna do that differently in the future.

  • Kelvin Luck says:

    I agree with all of the above and have a couple of others which help me sometimes (although nothing is 100% reliable unfortunately):

    Leave easy finishing up to the next day
    It's late at night and you are flowing well but are going to have to stop soon. Don't keep going until it's all done, leave yourself some "finishing up" to do. Then the next day you can get straight into it and have a headstart at getting into the zone.

    Get a good rest
    If you are tired then it's hard to concentrate. Sometimes the best way to deal with a fast approaching big deadline is to take a step away from the computer and get a good rest so you can come back to it and attack it with energy rather than feeling like you are banging your head against a wall.

    Exercise
    Seems to help recharge the batteries. Then again, I've been absolutely useless at that one on the current project so can't really make any claims...

    Tea
    And lots of it!

  • Robert says:

    nice post, I especially like the advice about completing the smallest task first.

  • Pete Lyons says:

    I'd add the following:

    The planning and reading hints are only useful for people who suffer from analysis paralysis. Many people don't think enough so actually doing those things would be useful.

    I also disagree about the 'don't code another thing'. Unless you can't put it down once you start I think this can be a great way to relax and rediscover what you love about development. This is especially true if what you develop can be used on your project.

    My one addition - and it's very close to your suggestion of 'pick the smallest task' would be to write down on a piece of scrap paper a very short list of some things you want to try and accomplish that day. If you ever feel like you're distracted pick up the paper and read it. It reinforces focus and as with your suggestion it lets you accomplish something.

  • Axthos says:

    I am in the perfect situation for that and i'm going to put these great tips into practice right now. Except the fact that ATM I have no other work partner to talk to, but I do feel the need to.

  • Sean A.O. Harney says:

    For much applications programming for small sized programs, a great deal can be done ad hoc. Usually only a small percentage of the code or a few algorithms would be complicated and much of the rest could be done as you go along.

  • entmike says:

    I agree with all this advice, and especially agree with headphones.

    One thing that gets me in a funk is if I know I have a meeting, even 4 hours out, it kind of looms over my head all day and tends to make me not as productive.

  • my best advices are :
    a. just do it! code the smallest thing each day to keep you on track. even the smallest bug you fix can be considered.
    b. document everything you find for later. create a todo list, even when there are thousands of tasks, just write everything down, and once in a while, sort the list and prioritize it.

  • Always break after a breakthrough

    If you are working on something you don't know the answer to or some god awful bug, once you hit the eureka moment and everything clicks into place, instantly get up and go for a walk or a tea or something. There's no better feeling than sitting down to a problem you know the answer to.

  • Ciaran says:

    "Communicate for no reason" made me chuckle. Can't work? Interrupt someone else so they can't either. ;)

  • Michael R says:

    Thanks for all of these tips, I have to admit I am guilty of spending too much time on the blogs / news, but its not my fault - they show up in Thunderbird taunting me to read.

    Also and to a lesser extent I had the ideology that if I work on another app / script I will get in the coding mood, but my groove when achieved just goes to the other app, then I can't put it down and get my work done.

    There is some advice that I can't follow - allowing buggy software out, well not too buggy anyways, I am working on a private B2B site for my company where the users find one small issue, even typo, and will consistently call and bother our staff until fixed.

    I am definitely open to advice there.

    Thanks for the article and the distraction, I am following your advice and going for a coffee.

  • jrgns says:

    Schweet! Liking it...

  • James says:

    Good list, reading this made me realize that I actually do a couple of these things without noticing.

    I take a shower when I'm in need of some focus. Relaxes me, makes it easier to get into my zone. Coupled with music, it's a solid 1-2.

  • bman says:

    That is my entire development method. Only thing different is I tend to replay Metalacalypse seasons instead of music. I could not believe I saw it in written form.
    Trying to explain how I work a piece at a time never helps, I will just refer people here.
    Awesome article. screw agile development, this is Slacker Development Super-speed Methodology. ++

  • Ali says:

    "Communicate for no reason."

    I find this acts like exactly like a reset button. It disturbs my PA though!

  • CodeJustin says:

    Great list mate, I would add:
    Go Outside
    I find that if I detach myself my the computer and step outside trying NOT to think about my project then when I return to the computer I feel more apt to do the project.

    It's hard to say becuase I often have those times where you would rather be doing something else than coding a project you don't enjoy much.

  • adam dreaver says:

    Howdy,

    I've been in a funks before and always get myself out by

    subconsciously applying many of the principles you listed. I've learned through

    hard experience that the advice you write is true. Sometimes you just need to
    program to get yourself in the mood to "Program", i.e. create quality software.

    I want to add that testing, debugging, documentation, research and various other

    design and organizational problems can be the death knell for a programmer if he

    is running on empty. By simply letting programmers do what they love and get into

    the mood, you can generate energy for the essential non-programming ( read:

    BORING, difficult/tedious non-technical tasks).

    What's interesting about this advice of "just program", a.k.a. Cowboy Coding is

    that it seems to contradict modern iterative software development paradigms.

    AGILE, Documentation/Feature/Test driven development,
    XP,
    SCRUM,
    etc..

    All of These models put emphasis on many non programming related tasks. Testing,

    debugging, documentation, people interaction (client review, client feature

    requests/change/management); and all of these models condemn programming that

    isn't apart of their carefully laid development method.
    What this means is the
    programmer is no longer a programmer, he is now a software engineer.

    The skills of a software engineer is vast. He must multitask between various

    interdisciplinary skills. He must be a manager, a team leader, a customer service

    representitive, a businessman and on top of this he must be a master programmer.

    It's easy to see how programmers can quickly lose interst and fail to get

    motivated in their projects. That's why it's so critical to let programmers just

    program some days. I'm not sure the advice of "Program on your project no matter

    what" is good here, because in a team enivornment I don't see how cowboy coding

    can fit in. Maybe you can explain to me how a programmer could just do his own

    thing in one of these development paradigms?

  • Great post. I think many of us suffer from the same things. I'd like to see a follow up on each point that expands on the topic and gives us more insight on why each one is effective, how to avoid pitfalls and other little tips.

  • Lex says:

    Some very good points. Thanx!

  • nickers says:

    :( Last tip just killed me. I closed editor immediately. Avoid planning and don't cram - it is sad, but I think these are 3 reasons I did not wrote anything for months(besides useless scripts & some code to "test something"). Thanks nathan, this short reading was a little shock for me :|

  • Eli B says:

    This is so relevant, i love it!

  • Elliot Rock says:

    Interesting points indeed. The planning one is interesting, not that I totally agree but we all have different methods.

    How to do lists, not To Do Lists at the end not the the start

    Excuse the heading, I note what needs to be done at the end of the day, either on the train home or away from the computer. I need my mornings to focus and I find if I spend time, like Nathan says, planning whilst in front of the geek machine it doesn't get me into the code-flow.

    It is also important to write lists of solutions not problems, even if the solution is simiply "Test something as a unit" rather that "This is broken". It is a GSD (get shit done) advice, note the way to solve something! Its about pumping the positives and not getting caught in the negatives.

    Paper not screen

    If you are stuck, contrainted by time and tired! Get away from the geek machine. Walk and use paper to write down a mass of ideas to solve - even if they are way off the simplest solution. There are techiques in creative problem solving which relie on a non-judgemental mind. Paper is great for a collection of brain storming ideas and disjointed flow, it connects a different part of your mind.

    Thanks mate, I get back to work now!

  • Tony says:

    This is the story of my life - too many distractions and always far more that I want (need) to do than I can actually get done.

    I first realised the benefits of playing my favourite music to help me focus years ago when I was at university. I would put an album on (see I told you it was years ago), sit back to work on a program, and the next thing I knew was the "click" of the head lifting off the record and the music stopping. I rarely actually heard any of the music.

    Today's distractions are far more than just background noise though. As you pointed out there are emails, phone calls, the need to send my troops back out farming NPC's on Evony (oops - scratch that...) and far more.

    It's a constant battle to try and focus, but I agree with you that sometimes it's better to get some of the smaller jobs out of the way. If you have 10 things to achieve, 8 of them are quick fixes and 2 are going to take hours, I much prefer to get the 8 quick tasks out of the way, then I can focus on the major tasks. That is of course unless another 8 minor ones come along, which happens too often...

Trackbacks/Pingbacks

  1. Zach Copley (zach) 's status on Thursday, 08-Oct-09 18:56:32 UTC - Identi.ca
  2. joab jackson (joabj) 's status on Thursday, 08-Oct-09 19:22:57 UTC - Identi.ca
  3. joab jackson (joabj) 's status on Thursday, 08-Oct-09 19:23:24 UTC - Identi.ca
  4. Destillat KW41-2009 | duetsch.info - GNU/Linux, Open Source, Softwareentwicklung, Selbstmanagement, Vim ...
  5. Brian Tanaka (btanaka) 's status on Friday, 09-Oct-09 16:17:13 UTC - Identi.ca
  6. Weekly Link Post 114 « Rhonda Tipton’s WebLog

RSS feed for comments on this post , TrackBack URI

Leave a Reply

  • webr3 avatar