views:

154

answers:

7

Everyone goes through stages in their job where nothing seems to work - you can't get your head around a project, your code won't work, you sit staring at a screen, trying to understand, and all that happens is your self-confidence takes a kicking. You go home at the end of the day with your lack of progress hanging over you.

This can be especially bad for those for whom programming is a defining feature - "I'm a programmer, but now I feel like I can't program..."

These phases inevitably pass, you have a breakthrough, your coworkers help out, but at the time they can be quite devastating.

What strategies do people have to deal with this kind of thing?

+3  A: 

Test Driven Development

http://en.wikipedia.org/wiki/Test-driven_development

Nothing can boost your confidence in your code more

[added]

While this is not a solution to each ad every problem you will come across, at elast at the and of the day, you know which parts of your application work as expected, and which don't.

Mchl
sounds like Andy already has some code that is not working, so a "test first approach" (like TDD) seems not so appropriate - but anyway, in a situation as described above, tests (written after the code) still help.
Philipp
Agreed, writing tests after code is much more tedious and less fun. Still, automated tests give the confidence that test-covered code works.
Mchl
Ummm... I'd agree with *automated tests* as they usually do increase confidence in the code base. But TDD? It's not a panacea unless it helps against smelly feet, too.
peterchen
No, it is not a panacea, as I noted in my answer. It is however one of the ways to increase confidence in your work.
Mchl
I agree that TDD introduces some aspects that iprove confidence in code base. However, switching to TDD for existing projects is a rather large move IMO... like transplanting a new head to get rid of the tooth ache.
peterchen
Switching entire project might be even impossible, if the current codebase is written in a way hat makes testing next to impossible. However, you can still write test for new code and/or for code being currently worked on/refactored (some testing is better than none). I'm working on such a project currently, and I'm experiencing these obstacles myself (I would kill the guy who've written this code, if he wasn't me actually :) )
Mchl
I see a big difference between "writing test code" and TDD actually - maybe there's a source for misunderstanding.
peterchen
Yes there is a big difference, I agree. It's that our discussion drifted from TDD towards applying automated tests in existing code.
Mchl
A: 

When I run into a road block that take any significant time to figure out I will go talk with a work colleague first. The next step is performing internet searches for possible solutions with various keywords and identifiers. The third step is asking a question within a forum that is specific to the language or platform. These forums can be Usenets or here on Stack Overflow. I feel talking through the problem does help a lot. If all else fails, ask Jon Skeet.

lordhog
+1  A: 

your coworkers help out

I'd say thats the most important part, grab another developer and spend 30 minutes pair programming on the problem together, I imagine that once you've taken time to explain the problem succinctly to your co-worker, and gotten a second viewpoint, you'll be pretty close to the crux of the issue, and can fix it from there.

I'd also second the TDD reference, when I have a complex bug to fix the first thing I do is write a failing test case which isolates the problem.

Jon Freedman
i.e. use your coworker as a "rubber duck".
Lie Ryan
+2  A: 

Help other people.

When I get stuck with something, I try to help other people with their problems. Getting in touch with other people and helping them with their problem is a HUGE boost for your self-confidence.

After that, get back to work and solve the problem (or let other people help you solve it).

Helper Method
+6  A: 

Don't judge yourself by the great code you've written today.
Programming is so much more than cranking out great code.

Find out why you don't feel productive.

For me personally, it's usually one of the following:

  • fixing non-code problems (such as build tools acting up, servers offline, etc.)
  • planning/meetings with only vague results ("we have to fix this somehow - this is important!")
  • finding five new bugs while trying to fix one
  • being janked out of the flow with a totally important new idea
  • some customers...

At the end of such days, I make a mental list of what I did today before I get home. This helps me shed the vague feeling of having spent an unproductive day.

Your problems might be different, so might be your solutions:

Just can't understand the code? Maybe you lack some form of better documentation.

Unsure what do do right now, or not confident that what you do is worth the trouble? That's often caused by bad management, can be fixed by better planning - you need clear milestones with easily tested goals. if you don't get them, set them for yourself.

Solution is more complex than you thought?
This can be caused by bad planning, or the anchoring effect (Someone expecting a solution in five hours makes us think it can't take longer than five hours - even if we know he can't tell a for from a fork, and even if we are aware of that effect. )

Don't try to solve all things on your own
Many of these problems involve your coworkers and your manager.

Have a list of other things to do
There are often low priority maintenance tasks, that get delayed and pile up. Having such a list might give you something more productive on days where you can't focus.
However, if you do that, also track the time spent on these low-priority tasks. Otherwise, you are just delaying your procrastination crash.

peterchen
+1  A: 

I think this is more general than to just programmers.

Some things that help me...

  • Do something else for a while, be it another project, gym, coffee break, etc.
  • Start a pet project that is fun and short (~day)
  • Work in proximity of the problem. For example, document the code, create test cases, clean up the code, etc.

As much as possible I avoid complaining about it, especially to co-workers. This can just create a negative feedback loop that can make things seem much worse than they are.

Basically, I try to productively procrastinate for the sake of my sanity.

ccook
A: 

Rather than finding ways of coping with it, I would invest time and energy in becoming a more experienced programmer to make these scenarios less common.

Please don't get me wrong. I am not saying you are inexperienced, but there is always the next level; and this applies to everyone!

I would definitely recommend reading The Pragmatic Programmer to anyone who hasn't already.

Jaap