Please Help Me Overcome My Programming Anxiety

November 14, 2013 6:56 AM

I am paralyzed trying to work on code. Not sure how to proceed.

Some background: I have a PhD in applied CompSci, most of my dissertation had me writing kernel level code for 2 years. In my PhD I probably wrote/read/modified approx 100KLOC of C code. I _know_ how to code and have done so successfully in the past.

It's been about 7 years since I actually did serious systems work. Now I'm getting back into it primarily because I was annoyed at my atrophying skill set and also because I have a lead on some research I want to do. However when I sit down at the computer to actually try and write some code I seem to "freeze" up. I can't seem to make proper progress and I'm continually second-guessing myself and thinking about whether I've done things the best way possible, whether it's clean, whether there's a better way of approaching the problem meaning I make little to no progress for days.

I have been analysing why I feel this way and I think it's a combination of:

1. Feeing judged -- I'm working with super competent experienced people who have been working on this problem and codebase for 12-14 years. They are seriously, seriously good. So I feel like a bumbling amateur.

2. Feeling frustrated -- I've forgotten a lot, and it's been a long time since I did serious work. I'm making schoolboy errors I should not, I'm having to relook up and relearn stuff I should know and have known in the past and this leads to frustration and slow progress which ultimately boils down into feeling overwhelmed with the task at hand.

3. Tight deadline -- Feeling I cannot make the deadlines, this gets worse with every day of zero progress.

4. Bad memories -- I remember the pain of coming into grad school as a fresh faced undergrad and the pain and suffering that followed hauling my skills up to the level I should have. I also remember the sheer frustration of crashing kernel code which turned simple problems into huge time sinks.

In summary I'm feeling ill-prepared and overwhelmed. I should know better but it's not helping. Talking to a friend about it he made a parallel with writers block/writers anxiety and I concur. I seem to have turned the one thing that I loved about computing (coding) into the worst thing ever. I need to reset this and I'm not sure _how_ to proceed doing so. Any help gratefully received.

posted by anonymous to Grab Bag (17 answers total)

Have you considered pair programming to help you get started?
posted by oceanjesse at 7:05 AM on November 14, 2013 [5 favorites]

Can you talk to any of your co-workers, tell them that it has been a while since you last programmed and you want to ramp back up as quickly and solidly as possible. Ask them if they could possibly mentor you for a while, double check some of your work, discuss your ways of approaching things, etc? Asking for help isn't a bad thing. Asking for help so that you can do the best job moving forward that you can is actually really smart.

Whenever we take on a new developer (or when we have someone come in that is unfamiliar with the system we are working on) we set up a mentoring system. Someone who is familiar and experienced with the code serves as their go-to question answerer, as well as someone who follows behind them and ensures that standards are being followed correctly from the beginning. It works really well and keeps everyone moving and working and it helps to keep the code written at the same high level.
posted by PuppetMcSockerson at 7:05 AM on November 14, 2013 [1 favorite]

You need to talk to your coworkers, I think. Everyone takes a while to get their sea legs moving from academia to doing real-world stuff, and they should know that and help get you into the proper work flow.
posted by empath at 7:06 AM on November 14, 2013

Been there. Felt that. Pair programming for the win.
posted by flabdablet at 7:22 AM on November 14, 2013

1. Is TDD applicable to your project? It is almost tailor-made to overcome fear and anxiety in programming.

2. This could be emphatically not true of your co-workers but I just have to say this, based on my 10+ years of experience doing programming, mostly on a consulting basis (meaning that I have been on dozens and dozens of different projects and teams). A lot of the time, people who present as intimidating are actually the least knowledgeable. Are you sure that your mental juxtaposition of super competent/bumbling amateur is not caused by your co-workers "using" you to assert their intellectual superiority? In my personal experience, this happens a lot on software development teams, and people who do this are supremely adept at making you feel that they are better than you. After a while you start to recognize them - these are the dudes who will say "insufficiently large" instead of simply "too small", or keep feeding you bits of information that appear helpful but just so happen to lead you on a wild goose chase every time - but you are fresh so you may be getting undully impressed.

3. Seconding everyone about pair programming, so long as you can find someone who will not use it as an opportunity to do (2) above.
posted by rada at 7:35 AM on November 14, 2013 [3 favorites]

Step away from the computer. Really.

Whiteboard or pen and paper, break down your tasks into small chunks. Pseudocode them. Add more details. Then boot up and start typing.

A competent, experienced, good programmer won't be judging you for trying and bumping against bugs. How do you think they got to be competent if it wasn't hours/years of what you're going to be doing now?

Frustration is just par for the course really, I've been programming full-time for the past 7 years and just spent 2 hours struggling with git/pageant/windows. It happens. Eventually you'll be good enough at what you're working with that these frustrating issues become few and far between. Then you'll start learning something new and start all over again!

On the bright side you've done this before so you know it's going to pass, you just have to hammer out enough code to get through the initial phase.

Pair programming has been mentioned, and I definitely agree about it. But if for some reason you don't feel comfortable with it, at least try and get someone to take a look at your pseudocode before you get started on the actual code. A code review could be handy too if you find someone willing.

If you're still feeling paralyzed about it, try and get into the mental mindset of making prototypes. You aren't writing final production code so you can work quickly to get the basic functionality out. Then iterate to polish it up gradually. I find that just finishing something small and getting some momentum really breaks the mental block.

Good luck.
posted by xqwzts at 7:48 AM on November 14, 2013 [1 favorite]

I'm continually second-guessing myself and thinking about whether I've done things the best way possible, whether it's clean, whether there's a better way of approaching the problem meaning I make little to no progress for days

I am prone to this. OH GOD am I prone to this.

The best solution I've found: build one to throw away. Don't even try to do it the "right" way, just treat version one as a prototype where you'll make all the mistakes, discover all the weird corner cases, wrap your mind around the whole problem and see how it all shakes out.

I frequently find that building two completely separate versions of a product, one quick-and-dirty and one more refined afterwards is much faster than trying to get it right the first time -- on the first go-through you aren't constantly haunted by the what-ifs and can just Get Shit Done, and on the second round you're not faced with the blank-page fear, you already have the whole problem laid out in front of you, and you can make informed decisions about which of the quick-and-dirty stuff needs to be repaired and which of it is maybe good enough. And when you get halfway in and discover that the requirements aren't what you thought, or that your model doesn't match the problem, or whatever -- which as I'm sure you know happens a lot -- you're much more likely to make the changes you need to than if you've already sunk tons of time into solving the wrong problem the "right" way.

Shitty first drafts: they're not just for writers!
posted by ook at 7:56 AM on November 14, 2013 [11 favorites]

In addition to the above, try setting super modest goals. Like, "Today, I will write a function that filters arrays for x." If it's feasible, write a test for it first that can be run easily without the rest of the code. Don't think about anything else, and don't focus on going fast. In fact, intentionally try to code slowly. If you end up getting that done, pick one more simple goal like that.
posted by ignignokt at 8:00 AM on November 14, 2013 [1 favorite]

Your years of experience is a bit of a red herring in my opinion. You might ramp up much quicker than someone fresh out of college, but your approach should be the same—

- pair program (I find this works best for me when I have a specific goal rather than just "refactor this code.")
- value other peoples' time, generally speaking.
- try to solve problems on your own before asking someone
- when you DO ask someone else, tell them what you've already tried.

You sound like a great hire. Communication skills and ability to pick up new skills count for far more than sheer programming knowledge in my book.

The good thing is that if you're working with guys that have been coding for 12-14 years, they will have worked with plenty of less-experienced developers and will be glad to share their wisdom if you ask.
posted by yaymukund at 8:08 AM on November 14, 2013

lot of the time, people who present as intimidating are actually the least knowledgeable. Are you sure that your mental juxtaposition of super competent/bumbling amateur is not caused by your co-workers "using" you to assert their intellectual superiority?

Yes yes yes yes!

I have been considered both the best person on the team, and the worst person on the team. Same me, same skillset. One place people helped me, at the other place (which had a ton of proprietary systems no one could possibly know from outside) people went out of their way to humiliate me for asking questions, talked down to me as if I was stupid, refused to answer questions, answered questions wrongly, and set me up to fail in a dozen other subtle, plausibly deniable ways.

"Pair programming" is a buzzword I wish would go away, but it can certainly be helpful to sit with someone cool and walk through something. Most teams have at least one cool person who doesn't take it as a personal affront to be asked for help. Yes, even in programming, there are people who LIKE to help others. Strange but true. A lot of times it just comes down to finding the cool person and avoiding the assholes.
posted by drjimmy11 at 8:30 AM on November 14, 2013 [2 favorites]

You keep saying "should". You should not be making errors, you should know better. But the thing is, you're just you. You should know exactly what you know now, which sometimes includes forgetting things. Any programmer, if they take even a few months away from their own code, forgets everything about what they "should" have remembered. You're holding yourself up to an ideal that you can't live up to, and frankly, you might not have lived up to even when you were knee deep in your PhD, since again, you're comparing yourself to people who worked on this codebase for a decade.

I have an MS in CS, and the phrase "you've forgotten more than I'll ever know" is never more applicable than in this case. You'll get back into it, and since you've already laid the groundwork for learning it before, you'll pick it all back up easier the second time.
posted by thewumpusisdead at 10:34 AM on November 14, 2013

ook: "I frequently find that building two completely separate versions of a product, one quick-and-dirty and one more refined afterwards is much faster than trying to get it right the first time"

I've heard this approach called "get it working, then get it right." I really like it too.
posted by yaymukund at 10:48 AM on November 14, 2013 [2 favorites]

No one has mentioned TDD, but if you are not using it, it can help you define your problem space and look at the task from a new perspective. Plus, seeing all your unit tests turn green can be a real motivator!
posted by SNACKeR at 6:20 PM on November 14, 2013

building two completely separate versions of a product, one quick-and-dirty and one more refined afterwards is much faster than trying to get it right the first time

That advice ("plan to throw one away") comes from Fred Brooks, who has since moved on, undoubtedly helped by the advent of decent version control systems. But there is certainly nothing at all wrong with starting out by doing a certain amount of deliberately broken and inadequate design, solely as a first foray into exploring the problem space.

Of course, there's a risk that deadline pressure will cause that broken and inadequate design to end up being sold as the final product. As emotional insurance against any such mismanagement disaster, I recommend including a standard comment block in the first version of any source file:

/* This is first-cut exploratory code that was never intended to
see the light of day. If you find yourself stuck with maintaining
this steaming pile, please understand that if I had been given
enough time to do my job it would long since have been replaced
with something much tidier. */

posted by flabdablet at 7:26 PM on November 14, 2013 [1 favorite]

I'm a career database/web programmer, and I've been dealing with anxiety which leads to procrastination for years.

Here's my process:
1) Recognize that you're anxious

2) Try to shove that away as much as you can - do breathing exercises, meditate, whatever will help you calm down a bit.

3) Concentrate on one miniscule aspect of the problem at hand. If you're writing a routine to, say, draw little calendars, first write a routine that draws one week. Break the problem down. If you have trouble with this part get away from your desk. Get out a pad of paper and pen, try flowcharting/pseudo-coding it.

4) With one part done, celebrate with a coffee, cigarette, whatever, then come back and work on the next miniscule part. The key to being a productive programmer is momentum, and momentum is just as many tiny little victories as you can squeeze into a day.

5) Don't forget to let your subconscious work on the problem. If you obsess about work in your off hours, you aren't letting your brain do its thing. Relax, watch TV, play video games, do some chores. Don't do work at home unless you're trying to keep up the momentum you've already created in a workday. If you relax and do things you enjoy away from the office, you'll find that the next time you sit down at your desk that niggly little problem you were working on has suddenly become really easy to solve. Brains are awesome.
posted by signsofrain at 8:58 AM on November 15, 2013

I've been writing code professionally for a long time and I still go through moments of "writer's block" where I just can't seem to move forward with a chunk of work, because it's too complicated or too easy to mess up.

I move past this by telling myself: "I'm writing this code to learn something". The only way I know of to understand complex systems is to interact with them in code, and record my learnings as I go.

Sometimes I throw away this "self-educational" code, sometimes I keep parts of it, but it almost always helps me get unblocked.
posted by bbuda at 10:42 AM on November 15, 2013 [2 favorites]

Nthing test-driven design (TDD) or at least writing unit tests, and writing them early.

Since they're just tests you can work on them without worrying about them being perfect (great for getting past a block). Then you can write your real stuff without worrying about that being perfect, since you can easily refactor later without fear (because you have tests).
posted by anaelith at 10:27 AM on November 17, 2013 [1 favorite]