Use of low tech tools when it comes to programming [modified]
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
Normally, anything new involving more than a single new data structure or class goes to my UML tool first, so I can sort out what the interrelations exactly are before I think about what methods and what data I need, and where. If I'm unsure what the actual objects are, then it's pen and (any kind of) paper first. The big advantage of P&P is that I can pin down concepts, methods, and data that I need without having to identify what type of UML object they would be, or where in my code to put them. Once I have an overview of the elements of the problem, I am ready to move on to the UML tool, or if it's clear enough, even directly to coding. I also often dig through a problem in my head while walking around, even going to the loo occasionally gives my great ideas. There even was an occasion or two where I literally dreamt up a solution to a problem I had (and no, I was not dreaming at the office ;P ). Another way of finding a solution is discussing it with someone else. In 4 out of 5 cases I suddenly see a solution just by going through the effort of trying to explain the heart of the problem to another person. I think just imagining to explain it to someone else would do the same, but in that 1 out of 5 case it is advantageous to have a real person to talk to ;)
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
The most profoundly useful tools are the following: - Two Uniball Micro[^] pens, one in blue, one in green. I've used these pens for 25 years. - Old sample cards. We use 5.5"x8.5" card stock for printing samples (we make commercial ink jet printers). I have a box full of these that have been printed only one one side. The cards are a nice size for outlining ideas, making bullet lists, and so on. I use them to keep track of all of my "number one top priorities". They're small enough to shuffle as needed.
Software Zen:
delete this; -
Whiteboard: A whiteboard helps me thinking and explaining. It's a bit quirky maybe, but works well. Post-its: When I leave the office PC's running overnight, I have to stick a post it "keep running" to it. otherwise, the one closing might shut it down. pen-and-paper: To-Do list on crazy days. I have a thin A5 ringbook that I use to put things into order of execution when I get ten issues with "top priority". I also use it to jot dowen notes, and do some minor design. I don't use it daily, though.
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighistpeterchen wrote:
When I leave the office PC's running overnight, I have to stick a post it "keep running" to it. otherwise, the one closing might shut it down.
If someone touched my PC when I wasn't here, the next thing you would see would be their head on a pike outside my cubicle walls. I have scheduled tasks that run at night to do backups and other sorts of maintenance. I occasionally start builds when I leave.
Software Zen:
delete this; -
I am like you - a HUGE fan of pen and paper. In fact, I overuse them; I am trying to use Scite/Excel more so I can mail my findings to somebody else directly. Just a suggestion for the paper users here - use the reverse of old single-side printouts. There is no dearth of documents printed but never picked up at my place. :(
Cheers, Vikram. (Proud to have finally cracked a CCC!)
Vikram A Punathambekar wrote:
use the reverse of old single-side printouts.
That's what I also mostly do :). I can throw them away once I have transferred my work to the computer. One thing I want to try is to see scan my writing and scribbling and preserve them.
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
I often use pen and paper to solve complex logic problems. I draw, write and make calculations no paper. It's far more efficient than the trial/error solution. Some things aren't as practical as using pen and paper. So, yes, this tool is more than welcome. Works fine with me.
-
And bugs.
Visit http://www.notreadytogiveup.com/[^] and do something special today.
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
It depends... easy things can go straight to code. More complex things/relationships I write on paper (or whiteboard when collaborating).
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
I think best using a whiteboard. Have a huge one covering one wall of my office. I usually work out whatever I need to on the whiteboard and then leave it there for days while I code it up or document it. At my previous position, the conference room was covered with whiteboards from floor to ceiling -- all four walls. We'd work out whatever we needed to and leave it on a section of the whiteboard for months. It wasn't uncommon for developers to get up from their desk and walk into the conference room in order to refer to the documentation. I prefer getting up and walking around to pulling something up on a screen. If I don't have a whiteboard, I prefer a pen a paper. I can draw anything I want with pen and paper, I'm not limited by what a computer program will allow me to do. Often after I've got it all worked out on paper, I can just sit down and code it without having to refer back to the paper -- and I comment as I code so the code is the documentation. So losing the paper isn't an issue. If I need to communicate the design to someone else, whiteboard is definitely the prefered mode -- and leave it there on the whiteboard until we've got it coded. That might mean covering every wall with a whiteboard, but it's worth it. Only problem is working with developers remotely.... Hmmm... Maybe that's why I have such problem with outsourcing pieces of my projects.
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
with VSTS 2010 Visual Studio will be our board! lol cool new features for UML however a nice really big white board is a must always before going for the mouse and keyboard
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
If it's something obvious and simple, I go straight to the IDE and get it over with. If it's more complex... I always sketch it out - rather like a crude flow chart - with all manner of scribbles crammed in. Walk away and think about it. Study my aforementioned hen scratch, then write coherent notes on how the program should flow. This is a habit I picked up in the 80's working with dBase. Once I can visualize it on paper, I begin coding in whatever environment is appropriate.
-
The problem with paper is that it has a great propensity to get lost exactly when you need it :). Like you, I usually use the backside of printouts, which doesn't help.
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
Rama Krishna Vavilala wrote:
solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper
I use IDE + text editor + pen and paper. It can be in any order and it's iterative.
Rama Krishna Vavilala wrote:
once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper.
I wouldn't like that because I tend to need to combine all the bits I listed to grok a problem.
Kevin
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
I find that if I just start coding I usually end up having to redesign something in the middle of it as I realize I missed something. Writing down the steps on paper definitely helps to make the coding part easier and quicker. We had a lecturer that told us that most of the time for writing a program should be planning and the coding is only the implementation of the plan.
