Explaining coder's block to non-coders(tommy.authpad.com)
tommy.authpad.com
Explaining coder's block to non-coders
http://tommy.authpad.com/understanding-and-combatting-coder-s-block
26 comments
The most common form of coders block for me does not manifest itself in the beginning. It often happens at the very end of a coding session or in the middle. I stare at the screen and blank out on what I was doing, and all the sudden things are mixing up in my head and I can barely right a for loop. Maybe this is more akin to burning out for the day then a 'block'.
coder's block? no such thing!
This sounds more like "designer's block". When you have the types of problems described in this post, you need to approach the design issues before you start writing code.
I'm currently working on engineering a new system to replace an existing, aging one, and I find the worst "coder's block" that I run into is when I've finished designing a component and I go to implement it. Something about the fact that I already know how it should look/run demotivates me from actually grinding out the code to make it happen on my screen instead of just in my mind.
The fun part is solving the problem - so then it comes time to code and you aren't solving anything anymore, just doing the drudge work of writing down the picture in your head. That isn't really fun at all. I find that having someone around who doubts that what I'm saying is a good idea. Something along the lines of "that won't work, it's all wrong" is enough to convince me to prove that I'm right, because darn it - I know it's good.
It's a cheap trick and feeds my own insecurities or superiority complex or whatever other pop psycology you want to throw at it, but it gets results.
It's a cheap trick and feeds my own insecurities or superiority complex or whatever other pop psycology you want to throw at it, but it gets results.
One thing I've found that works for me: stop designing before you've worked out every detail. Leave some design issues unsolved. Just get to where you believe you'll be able to solve them as you code.
That way, when you're coding your brain still has something interesting to chew on… and I find it keeps me from going too far off the over-engineering deep end.
That way, when you're coding your brain still has something interesting to chew on… and I find it keeps me from going too far off the over-engineering deep end.
I'm completely the opposite way, when I have no idea what its going to be, i'm not productive at all. However as soon as I have a clear picture, when the entire design is loaded into my brain I just shut out the world and write it down. In code. To me its an extremely satisfying experience.
Yes, it can be quite difficult to go from what you've designed in your head to cranking out something that is initially worse than you imagined. It feels like you already solved it, and writing the actual code is the boring part.
Same here. I think there was some theory somewhere that categorized people into "starters" and "finishers", which I think is partially accurate. You just need a teammate who is a "finisher" who actually enjoys doing the polishing.
An intern, got it. :)
In all seriousness, it's only a problem for me with bigger systems. When I've got smaller tasks, even boring ones, I can blast through them easily, but when I have to do both sides of it I require more self-discipline to get through the last pieces.
In all seriousness, it's only a problem for me with bigger systems. When I've got smaller tasks, even boring ones, I can blast through them easily, but when I have to do both sides of it I require more self-discipline to get through the last pieces.
I'm really bad at this.
I have half a dozen projects on GitHub where I worked hard for a few weeks, decided all the interesting code was written, and then never bothered to finish.
I keep saying that one day I'll go back and finish them, I just don't know when.
I have half a dozen projects on GitHub where I worked hard for a few weeks, decided all the interesting code was written, and then never bothered to finish.
I keep saying that one day I'll go back and finish them, I just don't know when.
this is also common for myself..
I agree, that's another level for me, the "ok now to starting typing.... AH THERE'S SO MUCH TO WRITE! How does writing this first line even get me remotely closer?" syndrome.
I solve that problem with 3 AM, coffee, and bad TV. Stay up late, get wired, and have background noise such that you get into a flow and stay there. Somehow, the Boomerang network (full of amazingly bad Hanna-Barbera cartoons in with some fairly good stuff) helps it along.
Is this issue common with personal projects? I've been a developer for almost ten years and never experienced it. What I do experience is the urge to procrastinate on hacker news :-)
I haven't ever experienced what is described either (in personal projects or professional work). What I find gives me "coder's block" is when I have coding tasks that need to get done, but don't really require any thinking. Tasks that are just beyond the threshold of being able to write a script to do them for you, but still feel like they are something that should be automated.
In this case I don't think it's a block in the same sense as writer's block, but rather a block due to a lack of motivation, because such tasks aren't enjoyable in the same way coding that involves creative thinking is.
In this case I don't think it's a block in the same sense as writer's block, but rather a block due to a lack of motivation, because such tasks aren't enjoyable in the same way coding that involves creative thinking is.
I never have an issue with this at work. Clients give us specifications, so deciding what I need to solve is never a problem. I definitely have this issue on personal projects though. It's often because I'm still trying to figure out the problem space.
I agree with nsxwolf, this is more of a designer's block than coder's block.
I agree with nsxwolf, this is more of a designer's block than coder's block.
I agree, and I have been a developer for much longer. Coders block? Never experienced it.
Creating the solution to a problem via code is easy, finding the correct design/implementation is much harder. I tend to write code first, refactor later.
Creating the solution to a problem via code is easy, finding the correct design/implementation is much harder. I tend to write code first, refactor later.
For me it's about establishing momentum.
1. Practice TDD: Start out by just writing a test. Then you'll want to write the implementation.
2. Set yourself up for the next coding session when you're wrapping up. Leave a line of code unfinished (dangling =), or leave yourself an empty method/function/block that's just waiting to be filled in.
1. Practice TDD: Start out by just writing a test. Then you'll want to write the implementation.
2. Set yourself up for the next coding session when you're wrapping up. Leave a line of code unfinished (dangling =), or leave yourself an empty method/function/block that's just waiting to be filled in.
Re: 2: A thousand times this. Stocking the pond with something easy for the first thing next morning is a great productivity hack. Usually I'll do the same sort of thing and leave a failing test case or a dangling compiler error to get my brain moving in the right direction the next morning.
Couldn't agree more. I usually try to take existing code that I know works, modify it with one of the more complicated functions I'm going to have to do, then when I get that working start writing out the structure for the new code.
That way, I've got a reward already set up: a function I know is going to work well!
That way, I've got a reward already set up: a function I know is going to work well!
I'd describe it more in terms of flow (aka being in the zone) & the lack thereof rather than as a design issue. When in that heads space everything just works, when not even the simplest data structure is painful.
Likewise. Flow is achieved with overlap of skills and a clear step by step path to a goal.
As a new full time coder, I experience coder's block perhaps few times a week at the job. I think tomasien's suggestion to write things down is very useful, something I've started doing and help me get through some difficult problems.
Specifically, it is helpful for anyone that is solving a problem whose scope is not clearly defined. Writing, instead of talking, helps to map things out and takes out the pressure in verbalizing an eloquent solution / interpretation, which usually comes a lot later in the problem solving process.
As a new full time coder, I experience coder's block perhaps few times a week at the job. I think tomasien's suggestion to write things down is very useful, something I've started doing and help me get through some difficult problems.
Specifically, it is helpful for anyone that is solving a problem whose scope is not clearly defined. Writing, instead of talking, helps to map things out and takes out the pressure in verbalizing an eloquent solution / interpretation, which usually comes a lot later in the problem solving process.
This resonates most with me. I get the low flow as I escalate the complexity of the problem cases.
seriously one can get coders block?? don't think i've ever experienced that. if i don't know something im in research mode. then back to coding again. i only experience 'block' like feelings when at a path in the road which requires me to pick from two solutions with equal pros and cons. could be that i code most everything bottom up, so its relatively easy to work on small tasks and build up and not have to think about the huge monster one is about to tackle.
Agreed 100%. Making the hard choices is where I might stutter, but I don't think I've experienced "coders block" as described in the article.