How do you keep your mind on a project?

[Ampera]

So I have a problem, something I'd imagine most, if not all programmers have had an issue with, but mine is quite deep. I'm finding it impossible to keep my mind on my projects.

I enjoy programming, I quite do, but it's almost impossible now for me to stare at a text file and /do/ anything for more than five minutes until I get almost restless and annoyed, and I just want to go do something else.
It wasn't always like this either, I used to be able to really put time and energy into a project, and have made incredible progress on stuff in a very short period of time for things like game jams.

This almost completely applies to programming. When I work on hardware or general software/system configuration projects, which I tend to do quite often, I will have boundless attention, to the point where I will put
more time into trying to get things to work than most people would consider even remotely reasonable (I just spent around 6-7 days straight trying to get a FreeBSD installation environment boot over PXE and /still/
don't have it working).

I do know that when I am in an environment where I have absolutely no other distractions, I will end up getting things done, but this isn't particularly easy for me to do. Transportation takes a lot of time, and my portable
gear is not pleasant to work on. (Would you want to program everything on a 14" tablet?).

I do also think that I might be setting some of my projects to be too lofty, but it's also one of the few ways to motivate me in general. If I don't think something is worth doing, I won't end up doing it, and most of the things I
consider worth doing tend to be quite complex and take a lot of time and effort to put into it.

I'm not exactly sure what I'm looking for here, mainly suggestions as to how people have solved this problem, experiences in general to see if I can extract something that works for me. Maybe I should just keep trying to go back
to it and not give up until I get somewhere. Maybe I literally should just work on things in five minute spurts, better than getting no work done at all I suppose.

[Psi]

Sometimes i find it easier to get work done on projects when i have less free time.

If i have lots of free time the value of this 'time' is low and i don't get very motivated to get stuff done.
When i have limited free time it seems worth more so i push myself harder automatically.

Maybe you need to do something else to make you want to do the projects.

[Ampera]

That makes sense, i just don't have anything else to do, as I have had an insane amount of free time for the past years.

[Psi]

Get a boring job you can do in your sleep.

You will feel motivated to do cool stuff

[SiliconWizard]

Not strictly related to software though.
It's a very common problem. I remember we had a whole thread about unfinished projects.

There is no miracle cure, but my point was that getting some external motivation, instead of relying entirely on your internal motivation, helps quite a bit. So for instance if you're working on a project that you know friends or relatives are interested in (or better yet, will use), it definitely helps. If no one is expecting anything out of the project (including yourself quite often!), it's almost impossible to keep focused until completion (unless the project takes very little time to complete). If you think you're expecting something out of it because, well, you want it finished, it just doesn't work. It's circular. It's not expectation. You need to want it finished for a precise reason. Whatever it is. But not just for its own sake.

Usually when you're younger, it matters less, because doing stuff in itself is fun and enough motivation. As you age, the fun in merely doing things decreases, so you need additional motivators.

Short of finding a purpose, as suggested above, another motivator, of course, that partially alleviates the latter problem, is to do something new. You'll get back some initial fun. If you've done programming for ages, you'd need to try something else. Could be analog electronics for a purely software/digital design guy. Could be experimental physics. Could be mechanics. Anything new really.

[james_s]

That makes sense, i just don't have anything else to do, as I have had an insane amount of free time for the past years.

I don't even know what that's like. Even if I didn't have to work I'd still have enough to keep me busy for more hours than are in a day.

[Psi]

That makes sense, i just don't have anything else to do, as I have had an insane amount of free time for the past years.

I don't even know what that's like. Even if I didn't have to work I'd still have enough to keep me busy for more hours than are in a day.

It always seems that way while you don't have the time. Ya have lots of enthusiasm to do stuff but no time to do it.
Once you have lots of free time things start out great but over time motivation to do those projects evaporates.

[Tomorokoshi]

One aspect of concentration is being able to get into the "zone", where understanding and productivity are high. Let's say it takes 20 minutes to get there when the conditions are right. However, in a typical corporate cube farm where one can hear typing from 4 rows away, there may be incidental and purposeful interruptions every 10 minutes. Therefore, one never gets into the "zone". Examples of external and internal interruptions leading to priority inversion include:

- Chatter about foolish activities like golf
- Inquiries from the boss about scheduling issues
- Quasi-spam email from the source control or agile task servers
- Questions about some other project from another engineer
- Compulsive checking of email, ebay, etc. on the cell phone

This is covered nicely in "Peopleware: Productive Projects and Teams" by DeMarco and Lister.

The trouble is that solutions to these are difficult. However, getting a start by being able identify the causes is required for any progress.

Productivity is like the weather: everyone talks about it, but nobody does anything about it.

[Bud]

I could not figure out if the OP was talking office/work  environment or personal projects or both. For working in the office the golden rule is:

!! Never take work home. !!

[ebastler]

So I have a problem, something I'd imagine most, if not all programmers have had an issue with, but mine is quite deep. I'm finding it impossible to keep my mind on my projects. [...]

I don't know what to answer without much context. Are you talking about work or hobby proejcts? Is the problem that you can't focus on the project because you have too many distractions (either in your immediate environment while you try to work, or thoughts in the back of your mind about other stuff you have to take care of)? Or do you have long, uninterrupted stretches of time but don't "feel like it" anyway?

[dietert1]

If you are free to decide what you will work on and you feel guilty of loosing focus to important projects or tasks, i recommend to check whether somebody is doing this to you. My personal experience is there are lots of people in this world who want to keep you from performing. Watch out if somebody is trying to nab you to one direction or the other. I've adopted the habit of turning off sound when ads appear on TV.

Regards, Dieter

[Ampera]

These are all personal projects, and I am unemployed. I have all this free time due to me being a student (sort of). This is why I have a lot of free time.

These suggestions are good though, and even though there's the ones involved in a working environment, I largely agree with them too. My issue is that I have no /need/ to do anything. I have the exact same need to program as I have a need to sit here and do nothing, so I'm trying to think of ways to keep myself more productive.

[ebastler]

My issue is that I have no /need/ to do anything. I have the exact same need to program as I have a need to sit here and do nothing, so I'm trying to think of ways to keep myself more productive.

That sounds like it is getting to the heart of the matter. So, are you genuinely interested in the results of the project? (Be it because you want a program that performs a certain function for you, or because you are curious about how some algorithm works and learning this is the result.) Or do you just feel obliged to do something, because doing nothing and just sitting there is "bad"?

If it's the latter, maybe you should let the projects rest for a while. Read some random books. Go for long walks. Wait until some question comes up where the answer really interests you, or until you have an idea for a program (or hardware gadget) which you really want to try.

Doing projects just out of a guilty conscience is not promising, and in my opinion is likely to make you feel bad about yourself when you don't "perform".

[Ampera]

No I have a genuine interesting in not just advancing my knowledge and experience in what is becoming more and more of a life skill, but in making properly useful and interesting applications.

I believe I have decent ideas, and I don't even have much of a problem organizing them. I don't think I have an issue in being in an eternal pit of, well what comes next. I just have an issue keeping with a project, or doing anything at all.

[NorthGuy]

Any project has exciting parts and boring parts. You must do both. When you have to stop doing something exciting and need to switch your mind to something boring, it is really really hard to do. And as you get older, it seems to get harder. But there's no way around this. The boring stuff has to be done. Once you clear your mind of your exciting ideas and commit to the boring work, it gets better, you can do it. Most importantly, you feel great once it's done.

[Ampera]

Any project has exciting parts and boring parts. You must do both. When you have to stop doing something exciting and need to switch your mind to something boring, it is really really hard to do. And as you get older, it seems to get harder. But there's no way around this. The boring stuff has to be done. Once you clear your mind of your exciting ideas and commit to the boring work, it gets better, you can do it. Most importantly, you feel great once it's done.

This isn't the boring part, there are the interesting parts, and I enjoy doing them.

[dnwheeler]

Here are a couple of things to try:

1. Play music that you are very familiar with - this will occupy some of the subconscious parts of the brain and let you work.

2. Have an alcoholic drink or two (no more) - this has been shown to calm down the brain and allow you to focus on one thing.

[magic]

Code: [Select]

unlink /usr/bin/vim
and build a dummy load or 74AC14 edge generator for relaxation

[Berni]

This is one of the reasons i don't want to be a programmer.

I think im reasonably good at programming, and i do find it pretty fun sometimes. When i am in the zone for it i can keep typing away for hours non stop, but when things just don't want to work or im fighting a bug that i have absolutely no idea why its happening or i find out i have to rewrite a whole pile of code because i suddenly found out i need it to work in a different way... etc. This quickly chips away at my enthusiasm for it. So i start taking short breaks of something else in between to not let it get to me. Eventually this goes far enough to where i end up mostly watching just youtube videos and messing about on the web all the time rather than actually getting anything done.

One good way to combat this is to have a very testing oriented workflow. Write code that can easily be tested by running it, put extra code in place that aids the testing process and reduces it to as few clicks as possible. Then develop the actual code in small steps at a time, as soon as you have something that could be run go run it and see what it does. This not only protects you from writing 2000 lines of code that ends up not working and you have no idea why, but it also feeds you little psychological rewards regularly. Every time you wrote more code, you run it and it works, then you get a sense of achievement that you did something cool. So since it felt good to get this piece of code working you feel motivated to write the next piece and get that reward again.

Another thing is to not overdo it. Even if you are really enthusiastic for that project don't spend all your free time coding it, you will eventually burn out on it. Do something else every so often. Things like taking a walk are often recommended, but i find that too boring (Even tho it does gives you great time to sort out your ideas on projects), so a good alternative are games. But you have to pick the right kind of games, its best to pick things that have little to no story to them. It should be something you can pick up anytime, play for 15 minutes to an hour and put it down anytime to do something else. Things like racing games, multiplayer shooters, ddr/GuitarHero etc.. but most certainly nothing with any sort of RPG element to the game

[NorthGuy]

... but when ... im fighting a bug that i have absolutely no idea why its happening ...

It's opposite for me. When I'm chasing a bug, I just do it non-stop without interruptions. It's hard for me to stop until the bug is fixed.

Writing something new requires thinking and it is important to finish the thinking before you start typing.

Write code that can easily be tested by running it, put extra code in place that aids the testing process and reduces it to as few clicks as possible. Then develop the actual code in small steps at a time, as soon as you have something that could be run go run it and see what it does. This not only protects you from writing 2000 lines of code that ends up not working and you have no idea why, but it also feeds you little psychological rewards regularly.

I also program in smallest pieces and recompile/test very often. But for different reasons. It's like picking a lock. If you can pick one digit at a time it's a piece of cake. If you must pick all the digits at once, it's insurmountable.

[Berni]

... but when ... im fighting a bug that i have absolutely no idea why its happening ...

It's opposite for me. When I'm chasing a bug, I just do it non-stop without interruptions. It's hard for me to stop until the bug is fixed.

Writing something new requires thinking and it is important to finish the thinking before you start typing.

Well i don't mean the kind of bug that appeared and you are methodically debugging trough it, slowly getting closer to its source. I mean the sort of bug that suddenly started happening at random. The bug disappears once you turn on some debugging tools, ends up being in connection with some poorly documented hardware and there is also a giant software library in the mix that you don't fully understand. Then once you think you have fixed it somehow it shows up again. These sorts of bugs that originate inside some black box of software or hardware, or evade attempts to methodically track them down. You read trough the documentation for the 10th time and its not behaving the way it says it should behave for whatever reason. Going trough this for a whole day just makes you want the damn bug gone so that you can go do something that's actually productive.

This sort of thing usually happens in bigger projects where there is too much stuff to have a clear overview of everything at once, the problem sometimes compounded that the project is so big because you been working on this for the past month or two straight, so you are sick of the project in general..

Hardware projects have the advantage of being more varied in the form of work you do like schematic design, parts searching, ordering, pcb layout, pcb assembly, testing, debugging, characterizing performance etc. And you are often forced to take pauses because you have to wait for parts to arrive.

[fourfathom]

I could not figure out if the OP was talking office/work  environment or personal projects or both. For working in the office the golden rule is:

!! Never take work home. !!

Back when I was doing product architecture and engineering management, I also did ASIC design in areas where I was the subject matter expert (or close to it).  I used Verilog to do these big designs, which isn't exactly programming, but quite similar.

I found that I did my best Verilog work at home, after the rest of the family had gone to bed.  At work I was constantly being interrupted by my engineers and marketing group, and the hundreds of other things that were a part of my job.  There was no way I could be effective at deep design work in that environment.  So my real thinking was done either during my commute (one hour each way), or between 11PM and 3AM.  When you are juggling a thousand virtual balls in the air and you need to know where each one is at all times, even a momentary interruption can cause them to all crash down.  It can take a long time to get them back in mental order.

And yes, I had to watch myself for the early-warning signals of burnout.  Fortunately by that point I'd had plenty of experience with hitting the wall, hard, so I usually managed to keep it under control.

So control your distractions however you can.  As suggested above, headphones and familiar music can help.  When your "flow" keeps getting interrupted you can get really frustrated and lose enthusiasm.

Another comment:  If this is a hobby, do give yourself permission to lose interest.  I personally find the very early stages of a project are interesting.  Once it stops being interesting I either find some other aspect that makes it interesting again or (if nobody is depending on me to finish it) I put it away and find something else to dig into.

[NorthGuy]

... there is also a giant software library in the mix that you don't fully understand.

If, before using the giant library, you think about your responsibility for all bugs contained therein, and the amount of time you would need to understand the library, you may figure out that the drawbacks of using the library outweigh the benefits, often by far.

Bringing huge amount of foreign code into your project contradicts the principle of developing the software by small increments and puts you into situation where you have no idea where the bug may be. It is hard to do even with your own code. But doing this with the code which is written by someone else, doing this with the code you barely understand? Not my cup of tea. If that's what the OP means by software development, I understand the frustration.

[Berni]

If, before using the giant library, you think about your responsibility for all bugs contained therein, and the amount of time you would need to understand the library, you may figure out that the drawbacks of using the library outweigh the benefits, often by far.

Bringing huge amount of foreign code into your project contradicts the principle of developing the software by small increments and puts you into situation where you have no idea where the bug may be. It is hard to do even with your own code. But doing this with the code which is written by someone else, doing this with the code you barely understand? Not my cup of tea. If that's what the OP means by software development, I understand the frustration.

I do agree, and i often like to write things myself, but as things get bigger it can become unpractical to write everything from scratch.

Things like a FAT32 library, USB device stack, Ethernet and TCP/IP stack, Optimised FFT, MP3 decoding, JPEG decoding, AES cryptography, RTOS... etc would be impractical to code from nothing as it would take way too long and would likely not perform as well as the existing libraries. Even peripherals on modern MCUs are getting so complex that it actually takes a significant amount of effort to write a proper driver yourself. But if you are writing software for an OS like Windows/Linux/Android etc... then libraries are your only interface to the outside world since an OS doesn't tend to let you touch any hardware directly unless you are a driver yourself.

These big imposing libraries become a necessary evil at some point. And even if you only work with registers directly you will eventually run into a peripheral with some errata in it where it does not behave like the datasheet says it should, and the manufacturer sure as heck is not going to give you the HDL source code for that piece of silicon, so all you can do is throw more trial and error at that black box until it does what you want. Can become very frustrating if this drags on for too long.

Programing was probably a lot more fun back in the 80s when things ware simple enough to not need all this crap.

[Ampera]

Some good advice here, that's because I follow some of it myself, 

I've worked to music, worked without music, both instances had benefits and detriments as music helps get me into a rhythm, but also helps to distract me.

I have a very simple method for doing little bits of code at a time. sh build.sh, ./testing/PROG, and I'm off (I should probably learn to use make one day...)

Other things that helped me is to write down my ideas so that I don't just go and start trying to program /something/ and not having a great idea of what that something is.

This all beside, I think my big problem is that I simply lack the motivation, depression or whatever it might be. Since they're my projects, nobody cares if they get completed except me, and I have a habit of not caring.
I've had video editing (granted not programming) projects that had money and actual events banking on it on a short deadline (few days), which was a great motivator, but whenever I start promising programming stuff to people,
I usually do it as a hobby thing, meaning even though I might disappoint people, just not /doing/ anything isn't really something that will hurt me. Doing things, however, is exactly what I need to do in order to get into projects where it
actually matters.