In the meantime, I can recommend the book "Decisive: How to make better choices in life and work" by Chip & Dan Heath. Its not self-helpy but very practical and succinctly lays out a set of useful techniques.
http://www.amazon.co.uk/Decisive-make-better-choices-life/dp...
For the example you gave, that type of indecision can be caused by lacking a specific goal so you don't have any meaningful criteria to separate the options. Clarify your goals in sufficient detail and the best option that supports your goal will likely become obvious.
If that doesn't help then one of suggestions in the book would be things like 10:10:10 where you imagine yourself 10 minutes, 10 weeks, 10 years into the future, and consider the best and worst outcomes of each option.
This is great way to pursue long-term high impact routes which can be clouded by short-term emotion. Conflict between short-term pain / long-term aspiration can be one component of decision paralysis e.g. learning Haskell today might be painful but life-changing whereas incremental python learning might be easy short-term but long-term low impact.
(Did a bunch of us buy that on a Kindle Daily Deal or something?)
I do think finally reading Knuth's work is helping here. As he manages to show just what that means. Far beyond anything I would have ever expected. And, amazingly, it is completely approachable!
Seriously, look at what I did here: http://taeric.github.io/Sudoku.html I still want to clean up parts it. Terribly so. What does this have to do with my day job? Really... nothing. Nothing at all.
Edit: More relevantly, what do my cleanups that I am obsessing over really help with understanding? Probably nothing. I just think I should clean up the function names and such. Stopping to actually understand how the fundamental algorithm works and where else I could/should use it isn't helped by my structuring the code differently.
You may really want to know what code perfection means to you, but you might also want to know what it's like to have a family, or run a marathon, or whatever.
Don't risk your job, but spending the time to make something as good as you can make it is often rewarding.
Not to be all morbid, but the clock is ticking, death comes for us all. If it's bugging you, you should fix it - even if no one else cares. If your own satisfaction isn't enough, you should set it aside and do something worthwhile. (whatever that may mean for you)
Also, I am literally the only person at work that will vote to hire someone regardless of whether they got all of the answers "right."
I've got the same layout at work and I'm even the go-to tech support guy, but when I want to get shit done I'm not afraid to tell anyone to stop bothering me.
One of my colleagues was a recipient of that dialogue and his working relationship with the other person almost ended at that point.
Headphones help, but unless you're a complete sociopath, it's impossible to not dedicate some amount of mental resources to human interrupt handling.
After seeing how productive I am during those windows of pure, blissful coder-escapism, getting back to the emails and little issues on GitHub and helping my coworkers... it absolutely shatters my productivity. Not because I don't like doing the little things (they give a zen-like satisfaction all their own, like a well-used checklist). It's the constant context-switching. When I do need to code, it's so tough to get into flow, knowing that I'm likely to be interrupted again at any moment by someone needing help with a bug, or some server or client that's on fire.
...
I was also tempted to request an "All of the above", as all of the issues (yes, all — I was tempted to check every item on the list) play into this, for me. Anything and everything can, and does, cause me to get out of flow — unless I isolate myself completely, and truly know that I am isolated. Then I can flow.
monday: app programming tuesday: web programming and management wednesday: app design thursday: app programming friday, saturday: anything, as long as its productive. not necessarily related to this project
i find that having a day to just play around is really helpful in keeping things fresh. if it weren't for that i would go bananas. great learning opportunities as well.
Experiment design is hard.
Edit: Actually, I've added it to "Office politics".
I would say Depression / Lack of interest / Feeling stuck would be what causes me to stop being productive, and reddit and hacker news browsing is a symptom of those.
#2 is the frustration that comes from bad tools. Spending 4 hours trying to get simple things to work while I crawl through config file hell. Msbuild, I'm looking at you. It kills my time and my motivation.
Codely? Codester? Codr? Namingway? Namegame? Codeboss?
Unless I can think of a pun or rhyme that clearly works semantically, then I almost never bother with "cute" names like that and just go either with unrelated nouns, or a boring description ("[thing]-finder") as a name.
On a side note, what is with all these startups naming their companies "noun-ly"? I find it kind of disjarring, nonsensical, and even annoying. At least the "twttr" type names I can sort of understand.
Unless we get to weird code wankery things where the variables don't represent real things but like mechanics. But that's far and few between.
val worldDestroyer = summonMe()
pick different days of the week/times for socialising and learning things. stick to them once you find the right balance.
Since it's harder to press that button than it is to type Command+T, I opened fewer tabs and was able to stay on task more. This is by no means scientific but curious to hear if it works for anybody else.
This never gets discussed enough. But if there is some thing else more interesting than your day work, your mind wanders off to the next easily accessible interesting thing. In most cases that is HN/Reddit/whatever. The problem may not be HN itself, but a rather more fundamental thing than that.
Every time I've changed jobs or projects, I've seen a sure increase in my productivity.
There fore if your productivity is just flat. Its probably time to check if you have a good enough project to work on, or check if there is other stuff like office politics and a unfair work environment.
Very rarely have I been in a situation where my productivity has fallen due to things apart from these. Even if it does, simple work arounds generally come handy.
I've worked on at least four teams since I joined (and a few smaller projects) - ranging from spam fighting systems, search infrastructure, internal infrastructure management systems, and now on the CDN team.
one thing that's helped me in the past few days is segmenting my to-do list into three columns: short, mid, and long tasks. anything under 10 minutes in short, 10-60 in mid, and 60+ in long. if i'm not feelin a long task or know i'll be interrupted soon, i'll pick something less time consuming. this of course hinges on knowing how you work and what you can expect.
EDIT: workplace organization and sleep have been problems in the past but not now, thanks to melatonin and a private office.
I think at the end of the day, our brains have a limited power to make tough decisions, and it's wise to clearly define a programmers tasks so he/she doesn't have to make them.
If I eat too much wheat I seem to get strong headache and tiredness one or two days after, but if I take my Concerta I won't be getting them.
http://www.theatlantic.com/health/archive/2013/12/this-is-yo...
Meetings, task switching, and status updates will frustrate me but I can generally get back on task fairly quickly.
Expectation makes me clamp up and produce work that isn't as good/gutsy/valuable. Social pressure makes me spend years on things I didn't want to be doing.
Really though I can get focus whenever I want, I just require 10 minutes of focus upfront in order for me to forget about the internet.