I'm a freshman Computer Science student and we just started doing some actual projects in Python. I have found I'm very efficient when I use the pen and paper method that my professor suggested in class. But when I can't write my problem down and work my algorithms out on paper I am really slow. During labs, I always seem to have to take the assignment back to my dorm. When I get there and write it out I solve the problem that took me the whole class in like 5 minutes.

Maybe it's because I get stressed seeing people solving labs before me. Or maybe it's the pen and paper method.

I was browsing through forums and someone wrote that if you have to write your programs on paper then you shouldn't be a programmer. I'm really worried because I'm so much better when I can see what the program is doing and track my way through it before typing actual code. Am I doing something wrong?

Edit: Sorry for being unclear, but when I said writing on paper I meant my problem solving approach (e.g writing examples, making tables with values, etc.) not my actual code. I just use the paper to get my ideas out.

  • 29
    I can't see anything wrong with thinking through the problem on paper first. Commented Sep 18, 2013 at 22:03
  • 2
    Possibly related Is handwriting out code an efficient way to learn a programming language?
    – user40980
    Commented Sep 18, 2013 at 22:03
  • 36
    That person is wrong. Most use shorthand like UML or pseudocode blocks, but whatever method you use has to work like your mind works and apparently yours needs paper =) I guess Feynman shouldn't be a physicist because he writes equations on the blackboard, right? Commented Sep 18, 2013 at 22:04
  • 11
    The challenge for you will most likely be learning to work things out on paper while you're actually in the lab. Engineers and scientists habitually use paper notebooks for this (and as a paper trail) and I've always wondered why so many IT people disdain that approach. I'm an engineer whose spent my career writing code, and using paper notebooks all the time.
    – Móż
    Commented Sep 18, 2013 at 22:42
  • 4
    @ott-- I and my co-workers all use pens with notebooks. For me, at least, it's a good trick I learned in college - being unable to erase helps force me to think it through more, so I don't end up having to spread it out across additional pages. Additionally, the temptation to keep it all on one page and the ability to erase makes it too easy to accidentally erase something you wanted. Incorrect approaches can also only be crossed out, not erased, so you have a reminder sitting there about what you tried and what doesn't work. Paper is cheap, don't make it harder on yourself.
    – Izkata
    Commented Sep 19, 2013 at 2:21

11 Answers 11


There's nothing wrong with working out your algorithms on paper first. Not so much for everyday coding, but for more complex algorithms, professional programmers work them out on paper or a whiteboard all the time, especially if a graphical format makes it more clear. For a student, every program is complex.

If you want to get better at designing algorithms at a computer, though, there are some techniques you can practice. Don't just start by writing out the code, write the same things you would put on paper as comments, then expand it into real code or more detailed comments one by one.

For example, if I'm deleting an element from the middle of a linked list, I might start with something like:

// find the element
// point the previous element to the next element
//    How do I get a pointer to the previous element?
//        doubly-linked list?
//        another find?
//        keep track during the first find?
// delete the element

Then I might replace // find the element with a function with more pseudocode, and keep going until I have a complete solution. Don't think code has to be written in a linear manner.

  • Good advice Karl.
    – andy256
    Commented Sep 18, 2013 at 22:15
  • 2
    I combine the above method with Rubber Duck problem solving (mine is a SuSE plush though) to do most of my complex work. I also have the luxury of a whiteboard to write lots of stuff out on.
    – Deco
    Commented Sep 19, 2013 at 2:23
  • +1. Writing questions and then answers is how I often solve things. It forces me look for pitfalls and gotchas in my plans.
    – Andy Hunt
    Commented Sep 19, 2013 at 9:42
  • 1
    You'll find a number of software development driven business will have writable surfaces all over the place. They're usually filled with diagrams, pseudocode, notes, the works. I've a very strong preference for scribbling things down. If I'm re-factoring code I love it if I can actually print the code out and annotate it. I find I get a much better feel for it than reading through and making notes.
    – Twirrim
    Commented Oct 6, 2013 at 5:24
  • 1
    This technique actually has a name: the Pseudocode Programming Process
    – roufamatic
    Commented Oct 7, 2013 at 16:51

Go for it! If we call what you are doing thinking and designing your solution, then it makes sense your process will be much faster than just blasting out code.

People like to think (and the noisy ones like to tell us) that their way of doings is better. But everyone's ability and skill mix is different. So do what works for you. As you gain practice, you will probably switch to doing more of the design work in your head, and use paper for bigger problems.

One thing to look out for is what form the exams will take. Will they be on paper, or will they be computer based? If they are paper based, then your way will give you an advantage. If they are computer based, then that's fine too: do any design on paper, then write the code. Whatever works best!

  • 1
    I can vouch for thinking and designing the solution taking less time in the long run. Too often, at university, I would see people (myself included) launch into 2 hours of clacking away, only to find that their solution was broken. Taking the time to design and work through the problem will help to find a simple solution. We have whiteboards, notebooks and "consults" where I work for this very reason. Commented Sep 24, 2013 at 14:57

I don't put actual code down on paper, but for anything non-trivial I almost always start out on a whiteboard or a notebook. I usually sketch out:

  • Algorithms/process/control flow
  • Data structures
  • Relationships
  • Components (how do I break this problem down)

It's usually a combination of sketches, pseudocode and English.

I find that by doing this, it's easier to visualize as I start coding. I also will spot flaws before I start into the code because I can see everything in front of me (instead of incessant scrolling and window-hopping). Not only that, once it's written out I can let things form in the back of my mind as I'm working on other tasks. I can also work in a non-linear fashion, committing an idea to paper when it hits me and then come back to it when I reach the point where I need it.

Committing something to paper is a tremendous help for memory retention. The tagline for the Field Notes brand of notebooks is this:

I’m not writing it down to remember it later, I’m writing it down to remember it now.

After taking a more focused approach to writing things down on paper, even if I make an entry in the ToDo app on my phone a moment later, I find that the thought is cemented in my head far better than just making the electronic note. IOW, by planning my coding on paper/whiteboard, the ideas stay in my head better.

It also serves as a handy reference when it's time to document what I've written.


I don't think there's anything inherently wrong with drafting code (pseudo or otherwise) on paper first - it's really no different than writing it out on a whiteboard, which plenty of people do when discussing how to tackle a problem.

Do you write first drafts of essays for non-CS classes on paper first before typing them out? In fact, I used to do that years ago when I was still a college student, but after my freshman year, I forced myself to write all drafts on a screen, since it made writing subsequent drafts so much easier, and the same idea applies to writing code.

I would suggest you try typing out your algorithms, even if it's just in a text editor like Word. The more you do it, the more comfortable you'll be at not relying on paper and pen. And if your typing skills are somewhat lacking and that's in fact the source of your frustration, take a typing course! It would be the best thing you could do for your future career.


Solving the problem and writing the code that implements your solution are two different activities.

If you're unfamiliar with a language, you're going to spend a lot of time on the code itself - and not enough on finding a good solution. If paper, whiteboard or starting at the ceiling help you in that regard, then by all mean do it.

(Personally, I find myself getting off the computer and walking around in circles trying to build a solution in my mind)


You will ace interviews! They make you write code on paper or the whiteboard. I'm the exact opposite. Trying to write braces or cut & paste with a pen is SO tedious!

My dad used a lot of paper when programming COBOL. I think it's just your style of thinking.


We used to have a two semester class named The Basics of Programming. Both mid-semester tests and exams at the end were done on paper. If you made any compile errors you lost a serious amount of points. If you made huge compile errors, you failed. However I feel it developed the ability in us to take a look at any code and find buggy lines in a relatively shorter amount of time.


There is nothing wrong with what you are doing, I learned to program using paper and pen as well.

As others have suggested do what works for you. I remember the first Java program I wrote was mainly on paper and then I spent two hours typing it up and fifteen minutes crying when I saw 200+ compiler errors. There were more but the compiler would only show the first 200! The point I'm making though is that by writing the code on paper I was able to think through the basic algorithm and functionality for what the program needed to do. The compiler pointed out the reasons why my program wouldn't run. 90% of the problems were out of bounds exceptions with arrays.

As you gain more experience and confidence you'll find yourself using pen and paper less. You'll already know how to use basic concepts such as for loops and so on. You'll have examples in other programs, which you can re-use. You'll use the compiler and an IDE to find obvious bugs during the writing of the program. Right now though you don't have that experience.

Reading through your question I wonder if some of your problems might be due to focus. If using a pen and paper in a quiet environment helps you focus then great.

You're still at college and you're still learning. Ultimately, all you're doing is what works for you. If by using paper and pen you are ordering your thoughts and thinking clearly and calmly then you are programming.

  • 1
    how does this answer the question asked?
    – gnat
    Commented Sep 25, 2013 at 11:23
  • The OP is asking if it is OK to use pen and paper since he read 'someone wrote that if you have to write your programs down on paper you shouldn't be a programmer.' He also states that he is at college so is still learning. My intention was to show that there is nothing wrong with what he is doing and I learned to program using paper and pen as well. Commented Sep 25, 2013 at 13:20

My code is much better organized when I scribble notes and approaches on a notepad, check books, check the web and think about it. I'm also much more of a visual person, so drawing pictures with data structures is very helpful. I don't write down every line, but I do scribble what I consider "important" fragments or key functionality. For bigger projects I fire up Visio. I'm not sure why someone would advocate jumping right onto a keyboard unless they're much more efficient, or paid by the hour.


Do what works for you. I wouldn't write code on paper. I do write pseudocode and draw flowcharts on paper, but writing the full code seems like a waste of time.


I am also facing same problem at my initial day' of learning technical skills.

But this type practice should not give the 100% success because if we are writing code on paper then there is no chance to bug fixing, there is chance to resolve the errors and exceptions during doing paper work.

So paper work doesn't give the any navigation to resolve the issues.And we can get type speed as bonus due to system practice.

I am also doing paper work but when before implementing my functionality just do rough estimation after this I will start My implementation on system.

Please try to spend more time on system practice. This will give 100% confidence and result.

Not the answer you're looking for? Browse other questions tagged or ask your own question.