I do this as well. I kind of take an outline approach with the comments. I find things that will need to be re-used and other types of refactoring kind of just pop out.
It's actually a very quick, useful reminder for me that 'hey, there's this other creative medium for designing things', but wow, you weren't kidding about the analogy.
There's something there, I think, but it would have been much better without the bit about bikeshedding, or reordered.
I do this for things that require a lot of thought, but I tend to do it with pseudo code and little scribbles on the side (tables of variable state for loop count 1..x, etc) and not worry too much about syntax, scope, and so on. Usually that gets to a point where I can put the paper down and try it with real code.
It's something that I'm still trying to force myself to do. I do know that I'm more productive away from the computer. But it's so tempting to just tweak, compile, test, iterate... I generally use pen and paper when I'm stuck and require deeper thinking.
Also, a lot of the work of a programmer consists in understanding existing code. You need the computer for that.
I have to agree with your other comment. Drawing things out on pen and paper helps me a lot as well, but it’s quite difficult to do when you need to work around existing code and keep all the classes, methods, and logic in your head, looking up things as you go.
I've never really had success doing concept work of any kind with pen and paper. Especially writing, but even diagramming. If I need to step back and work with ideas abstractly, the paper medium is still going to get in the way at least as much as the digital text does. What I really have to do is keep it all conceptual in my mind; that's the only medium that's truly unopinionated and flexible.
Paper/whiteboarding is more for communication to others, in my experience
Can I ask if you ever had any kind of art/drawing type of classes? I very often turn to sketches as my first attempt. I will often turn to paper first. I can sketch things faster than using something like Sketch. Maybe it's because I come from a wood working background where rough/not-to-scale sketches with dimensions written in were common just to double check your cut lists. Mearsure twice, cut once.
Also, I'm old enough to not have always had electronic devices, so sketching was all we had. In college, I didn't live on campus while living with my parental units an hour away. With the limited access to the computer lab, I would hand write code on paper and then transcribe. Then, right at the end of lab time, hit print so I could continue debugging by making notes on the greenbar print outs.
The problem I run into when I'm brainstorming or thinking about high-level architectural/modeling questions, is that if I start drawing something I get focused on how to represent my current idea and I stop actually developing the idea itself. And then if I change my mind, I have to go back and erase or strike things out instead of just redirecting my thought. Etc.
Usually if something is new for me or ill-defined, I take a walk or a shower and work through a rough idea of the big picture (usually realizing and iterating on some of the high-level problems) without any medium.
And then when I sit down to start seeing what that established will look like more tangibly, I usually go straight to the computer. Though I will say, I sometimes turn off type-checking when I'm just writing the idea out the first time. It can get really distracting when the code is going to be "broken" for the first 90% of the process. Once I've given it a look over and feel good about it, then I turn editor hints back on to nail it down and get it running.
For diagramming, I really only do it to document connections between things. Everything is either a chunk of text, optionally in a box or circle; a line or arrow; or a note beside the first two. It emerges directly from what I'm thinking without much extra thought, and usually gets discarded or rewritten before anyone else reads it, or if there's too much crossed out.
Sort of like a swap file, where if the number of items gets bigger than my working memory, I dump some of them onto a sheet of paper rather than thinking about all of them at once.
I'm interested in hearing how other people approach diagrams, because I bet there are a lot of different approaches, and no one size fits all.
Right but as soon as I've written down a blurb or drawn a line I feel like it's set in stone a little bit. It feels like a decision. It isn't necessarily - I can always erase it or draw it again on a new page - but that carries friction which interrupts the process.
It works better at the phase after ideation, where I'm pretty sure I have the major ideas in place and I want to see them to make sure they make sense. But even then I prefer a digital medium because of how easy it is to delete or modify (even an eraser leaves behind a smudge, adding something to a list on paper means moving each item by hand, etc).
>Right but as soon as I've written down a blurb or drawn a line I feel like it's set in stone a little bit
Use a pencil, and not a pen ;-) Much less permanent. Just knowing you can erase should make it feel less decisionish. For me it's the opposite. If it's a sketch on paper, it is so much more transitional. Once it's in code and executable, it makes me want to keep forcing things until it works. But that's what makes it fun. Each dev sees the same problem totally differently and approaches it in their own way.
I identify with this so much. Pacing, talking to myself even yes, but always manipulating concepts in my mind - and writing the code once it becomes clear. The idea of introducing diagrams or sketches into that process sounds disruptive and distracting at best.
I suggest that you maybe looking at/doing it wrong. See my other comments in this thread for some notes that may inspire you to give it another try but with a different mindset. The reason i say this is that i used to be in the same boat i.e. i can do everything within my head and don't need any external crutches. But once complexity really swamped me (it has become the norm now) nothing but pen and paper has helped me to effectively tame it. See also Dijkstra's paper, The Humble Programmer.
Maybe because it's so different? Is there a law that groups tend to fight more with those only slightly different? Like the People's Front of Judea probably fought with the Judean People's Front more than with the Romans..
It's because the real conflict (up front design vs finding as you code) is hidden by the small quirk of writing code with pen and paper. Rename the article "why TDD is useless", change the angle a bit and you'll create way more controversy.
That's a good point, you could indeed run the tests in your head. I think I can still save this though: this would prove that you only test for what you think about, and thus the existence or the absence of a test doesn't affect the development at all. Which could be countered again by property-based testing, but this one won't work in your head or one paper.
I found it very helpful to review code on paper. After writing a gnarly algorithm, my favorite way to scrutinize and improve it is to print it out on paper, lie on a couch, and mark up the text with a red pen. I focus much better this way, away from an interactive computer.
I did that once: had a Unicode related bug somewhere in a code that fit nicely 2 A4 pages so I printed them and debug when have lunch with a friend. I was able to think a quick solution that involved few changes, probably not what I would have been go for if using a computer. One of my most debugging experience so far. Also I fixed another bug (or more likely something not in the requirements at the time) and still use that portion of code today.
I tried pencils but I find text written pencils to be too faint. I find it uncomfortable to read. But pen writes text in bright blue color which is more pleasing to read.
You have to read up on "Lead Grades" used in Pencils; use 2B or 4B (or higher) to get dark, clear and smooth writing. Another factor to choose is the "Lead Diameter"; use 0.7mm(ballpoint fine)/0.9mm(ballpoint medium) for thicker lines.
Oh Man! I went down this rabbit hole quite recently and hence have plenty of information (Note: always check reviews first on Jetpens, Amazon and Youtube ;-)
My current favourite is the classic Tombow Zoom 505 series - https://www.tombow.com/en/products/zoom_505/ Not too costly, well made, elegant and professional looking. I have the Rollerball (i.e. water-based ballpoint), Mechanical pencil and Multi-function pen all in Black.
Multi-function pens (which have 2 or more ballpoints and a mechanical pencil) are another must have (I limit myself to 2+1). Buy a good professional looking one (eg. Cross/Zebra/Pentel/Rotring etc.) rather than the cheap plastic ones (they look ugly).
Many of the OEMs who actually manufacture the pens but which are sold under other well-known brand names are now releasing them under their own name. Two of them are TWSBI(Taiwan) and Penac(Japan). You should check out their offerings.
Finally, always check the offerings from Japan (Amazon.co.jp and Jetpens are your goto sites); they make some of the best and most innovative stationery.
I for some reason don't like the Parker Jotters as they are too thin for my fat fingers. Also the blue color of the ballpoint is too much on the purple side and gives me a headache. I too have one but I don't use it much but I still love it ;-). I am aware of their Gel lines but not sure whether they work for the Jotter.
>Finally, always check the offerings from Japan
I love the Japanese offerings but I don't get much in India. For eg Pentel has its factory in India but manufacturers limited set of models. I love Pentel pens btw but I am not satisfied with its offerings in India.
I am currently using Uniball Signo retractable UMN 207. Although the build and the ink is very nice it skips a lot and I am not sure whether it is because the ink is not designed for Indian weather or paper quality. I do see people having complaints with skipping but not much. I have ordered some UMN 307s and have to see how it fares.
>Many of the OEMs who actually manufacture the pens but which are sold under other well-known brand names are now releasing them under their own name. Two of them are TWSBI(Taiwan) and Penac(Japan).
I am thinking of buying the TWSBI as I really love its unique see through styling. I was thinking of purchasing a Lamy though. I am afraid to use Fountain pens as I work in harsh environments and I am not sure how it will fare but then again our ancestors were using these pens with ease. :-)
>If you are a Fountain Pen connoisseur, you should know that India has a large number of Artisanal Specialist Fountain Pen makers
Yes I am aware but the problem is I think they they import their nibs and just make the body of the pens. Somehow I don't feel like buying this Frankenstein and would love to buy the complete product if they make it.
Make sure that you are not confusing "Parker Jotter" with "Parker Classic"; they look similar (the stainless steel ones) but the latter is thinner which many find uncomfortable. And i replace the blue refill with a black one as soon as i get one.
You can find Japanese offerings on Amazon India and if needed, get it directly from Amazon Japan (i do both). You can also contact the resellers (who import from Japan and sell on Amazon India) directly for a better deal. For example, you can get the Tombow pens from https://www.foremostindia.com/
You should also check Aliexpress. I came across a rollerball pen which can be refilled like a Fountain pen which is neat.
Finally, your quote
>Yes I am aware but the problem is I think they they import their nibs and just make the body of the pens. Somehow I don't feel like buying this Frankenstein and would love to buy the complete product if they make it.
This is quite the wrong way of looking at it. These guys are very good and are optimizing their product based on their available skills. Making a nib requires metallurgy, high-precision CNC etc. which as small specialized Artisans they cannot afford to setup. So they focus on what they are good at (this is exactly similar to specialized Artisans in Germany and Japan; you find entire video series on Youtube; eg. https://www.youtube.com/watch?v=f5dekz26Kdw). For example, i have a Tombow pencil sharpener where the plastic body is made in Vietnam but the blade itself is made in Germany!. If you are a Fountain Pen guy you should definitely get one or more of this.
Finally, i should note that a lot of branded Pens are manufactured in India; eg. Parker Pens are manufactured by Luxor India and exported.
>Make sure that you are not confusing "Parker Jotter" with "Parker Classic"
I don't think so. It is a "Parker Jotter Standard CT Ball Pen".
>You can find Japanese offerings on Amazon India and if needed, get it directly from Amazon Japan (i do both). You can also contact the resellers (who import from Japan and sell on Amazon India) directly for a better deal
Won't this be too costly due to import taxes?
>These guys are very good and are optimizing their product based on their available skills. Making a nib requires metallurgy, high-precision CNC etc. which as small specialized Artisans they cannot afford to setup.
I think Ratnam makes the complete product. I must say that I am not much into Artisanal pens though. Similarly I am not much into funky anime type colored pens from Japan. :-)
>Finally, i should note that a lot of branded Pens are manufactured in India; eg. Parker Pens are manufactured by Luxor India and exported.
I don't like Luxor very much. I think there are quality control issues with the Parker pens as there is a lot of rattling in their jotter pens. I researched and found that it is not universal and was pretty pissed off as the Jotters are not cheap. Another reseller is Linc who are resellers for Uniball and they don't care about what they are selling. Similarly Pentel has a measly collection even though they have a manufacturing plant in Gujarat.
In my school days I used to use a Hero Fountain pen (Currently Shanghai Hero group) which was pretty good and my daily driver. My mother still had her beautiful Pilot pen from the 70s which I started to use later. I also sometimes used to use my classmates Butterfly pens too. I bought a Hero fountain pen in 2008 and it was horrible. Not sure what happened to it.
Heh... Growing up in Jamaica in the 80's, my brother and I wrote code on paper this way, before we got a computer.
We bought the books, wrote the BASIC code and rewrote it many times until we thought it was good.
Once the computer came though, all that went out the window. But to this day, my desk is covered in notebooks that help me visualize problems before writing any code.
I sketch out UI. Design database schemas. Draw data flow diagrams and end up with many, many, many notebooks finished up every week. I don't know if it makes me any better as a developer, but whenever I do it, I feel more confident approaching the computer and working on a solution.
You remind me of the brothers I know from my village in India, They are much older than me and their room were filled with CSE books, notes and computer came late.
One of them graduated from IISC, Top rank holder in all-India entrance test for it, is at top position in a leading SW company abroad and another runs a SW company in our city with about ~ 100 employees for 25 years (he's content with the scale); Many of his ex. employees are at top positions in FAANG.
I guess the story would be same for many from GenX who have made themselves a great career in IT but couldn't afford a computer when they were studying.
All of Dijkstra's EWDs are manuscripts[1]. As far as I know all of his seminal algorithmic work was done with pen and paper. When he was first programming it was just after the second World War and Dutch programmers could only manage to beg about 1 hour of computer time a week from the US occupation. So they got very good at writing programs with the technology they did have, pen and paper. As always, restrictions breed creativity.
I personally really enjoy pen because it makes you own your mistakes.
Hello, my fellow Dijkstra Fan! I too started to push myself to use pen and paper before coding because i was inspired by his EWDs. Being one of the greatest proponents of Method/Discipline/Rigor in Thought i figured it would be wise of me to emulate the Master unquestioningly. And it worked!
I think a lot of people here are not getting the gist behind the use of pen and paper; so let me try to summarize it;
* They do not limit the concrete expression of any concept/thought that you might have. You can use text, symbols, invent new symbols, connect them in any fashion you choose etc. etc. They are free form and become an extension of your mind. See also the book; The Body Has a Mind of Its Own: How Body Maps in Your Brain Help You Do (Almost) Everything Better.
* They force you to slow down your thoughts i.e. still your chaotic mind and help focus on the problem and its various aspects. This is invaluable in today's world filled with distractions. The books by Cal Newport are applicable here.
* If you choose to make your notes public, it adds another layer of discipline to really understand the subject matter since you have to anticipate possible objections and have the answers ready.
* Finally, they help clear your mind of the inessentials allowing you to ruminate and manipulate the essentials more effectively. Yet ancillary data is always available as needed.
If you look at History, all the greats wrote prodigiously. I firmly believe that it was one of the defining factors which directly led to their eminence. I was first inspired by the Notebooks of Leonardo Da Vinci (get the 2-vol large prints by Dover) before i started noticing the pattern.
PS: I read somewhere that Dijkstra wrote one of the first Operating Systems; The "THE" Operating System by hand on paper!
I used to code in pencil during the day at school, so I could test when I got home (and avoid boredom). These days I'll still sometimes use paper if I'm trying to optimize some inner loop assembly, easier to draw the code and the data side-by-side when both are changing.
Edit:
This line resonated with me:
> Maybe someday I’ll be able to handwrite code on an e-Ink device and then run it.
Are there successful projects for pen-based programming? I've read about Grail as a historical footnote, using hand-drawn flow charts: https://wiki.c2.com/?GrailSystem
I'd also be remiss to not mention Ken Perlin's Chalktalk project, though that's mostly a presentation system as it stands: https://github.com/kenperlin/chalktalk
These are both largely graphical and gestural, with a good number of low-stroke symbols instead of handwritten strings for the most part.
On a similar note as the author, I enjoy stepping away from the screen to code, though it's mostly for problems I'm stuck on. There's been many times where I've been lying in bed thinking about a problem and I suddenly think up a possible solution in my head and then run to my computer to type it out to see if it resolves the issue.
When starting on a complicated program, I've learnt over decades that the longer I draw diagrams and write code on paper before turning to the computer, the clearer I am about the program and the quicker it gets done. When I get totally clear about everything, the code writes itself, and I can write it down on paper as fast as I can write. Plus then when you type it in you can really 'write clean code', or halfway clean anyway. If I start typing straight away, it tends to be spaghetti.
This may seem pedantic, but this is an aspect of project management. The pen and paper aren't in the coding, they're in the design.
You may be doing some abstractions/pseudo code on paper but you're not coding. You're planning.
There's nothing wrong with this! I think it's a great way to operate. But it's less sexy to say "How I Plan: Pen and Paper" then to conflate it with coding.
Everyone does planning. Some people do it on-the-fly while coding. Some people do it in their head. Some people write it down.
No, the author is actually writing code using pen and paper. It's not just a high-level or organisational sketch. It's not just planning. What happens at the computer afterwards can best be described as transcription and debugging.
> I opened my laptop, created a new Github repository, typed in the code, added some tests and wrote the README. It was probably all done in 4 or 5 hours of concentrated work.
Means handwritten code verbatim went into the repo. The focus on iteration is great - it would be unusual to stop at this point.
But if we say the written word is canon, my response is that's inefficient. It is indeed the planning that is most valuable when putting pen to paper.
This semantic discussion seem pretty pointless as it doesn't focus on the whole idea behind the article. It really doesn't matter what definition for "writing" you use.
No, she probably kept editing it after she typed it in; aside from debugging, I always find things I can improve when I'm typing in code I wrote on paper first, so I do. But that doesn't mean that what she wrote on paper wasn't the code for the module. I mean, you can see some of it in her photos. It's syntactically valid C and Ruby code, semicolons and all.
As someone who's worked a fair bit now - coding has absolutely no value to any company. What delivers results is deploying solutions - whether those solutions are powered by hotpockets and red bull at 3AM or whether they are entirely composed of meetings discussing how to inform customers of the change - it is never "coding" that solves a problem. "Coding" is at most the effort of transcribing a solution from your brain to a computer - most devs will iterate over several drafts during this process. If, instead, you iterate drafts on paper and then just type up the solution when you're happy with it - it makes no difference - you've still delivered the solution.
The author is conflating coding with solution planning in a pretty minor way - you're more seriously conflating coding with solution building.
Coding often gives feedback on your plan and design. You may not see its flaws as long as its only in your head or on paper. When you write the code and try to run it on your computer you often realize something is wrong with it.
Architects do a similar thing, they visualize in their heads and on paper, but then they also actually build 3D small-scale prototypes to get feedback on their design.
So I would say that coding can also be an important part of the design process. It is not just transliterating what's in your head to code-files on the computer, it can help improve the design which is in your brain.
this is why I made the question about coding being called 'typing', in writing, coding or anything similar when you are at the 'typing' stage you will often revise and think more about what you are doing, add in conditions for edge cases and so forth. It is not just transcribing the thoughts you have already had, it is developing those thoughts at the same time.
Like another commenter said, it’s probably just semantics, but in software most don’t share a common educational background and language. The SDLC [1] is used where I work and coding / typing is called development. It’s where the actual code is written.
I think it’s always true that there is some time spent figuring out what problem is being solved, what needs to be built to solve the problem, building something, and making sure that it solves the original problem.
In mechanical or electronics it tends to be called manufacturing instead of development. In civil engineering or architecture it tends to be called construction instead of development. I think the difference in creating software is that one person can do all phases. They can even do the phases without formally documenting anything. The phases can be much shorter and iterated on much quicker in some software projects. I think when the software projects become larger and require more developers that they tend to have a more clear demarcation between phases and use more formality in documentation.
I think it would be more beneficial to the software industry if everyone was working with similar enough terminology that discussions don’t end up revolving around who is operating under what definition and which definition is best. But at the end of the day that’s just my opinion.
> As someone who's worked a fair bit now - coding has absolutely no value to any company. What delivers results is deploying solutions...
I don't see how some solutions not requiring code means that coding is not valuable, as some solutions evidently do require code.
When the solution requires code, the code is the solution, whether it's written in pseudo code or a language. I don't think there is a line separating the two. Just like language is thought.
Your "deploying solutions" could be replaced with "deploying code" (whether created in house or third party).
If your solution depends on code, then the quality of that code will also be important, which will include aesthetics, design, readability, tests.
In the long run, this is valuable, as you can't regularly and reliably ship the solution, unless you're confident it still works.
I seem to keep reading what appears to be this nugget of wisdom about building solutions rather than coding but I can't tell if I'm missing something or if I just consider the distinction to be sort of obvious. Can you please help explain? My reasoning is as follows.
So if you're a programmer then you're in the business of building software solutions which are generally built via writing code or script of some sort.
If the problem is best solved via a method other than writing software, then that's great. Not every problem needs software. Not every problem even needs solving either.
If however the problem does need a software solution then it's obvious that you should make sure you actually understand the problem so that you actually solve it.
I guess I just don't see how coding isn't equivalent to solution building unless what you call coding I call typing. For me thinking, researching, investigating, designing, engineering, planning, and even just "sleeping on it" are all part of the coding process.
I suppose that if the purpose of your coding is to learn or play then you might not be building a solution.
> The author is conflating coding with solution planning in a pretty minor way - you're more seriously conflating coding with solution building.
I don't think so, or perhaps expressed myself poorly. Planning is a critical part of solution building. Coding is putting the pieces together.
Unless you're absolutely winging it, you're mostly doing planning and then execution. My argument is the planning - the most important part of solution building - is what's being done on paper.
Then it goes on to explain that the author wrote out a Ruby/C module in her notebook before she "created a new Github repository, typed in the code, added some tests and wrote the README."
Since it's against the rules to question whether you've read the article, but people on here call each other liars all the time, I am forced to ask you why you are lying about what the article says.
We write code in paper, all the way upto college. Sometimes you get the privilege of a lab, but everything is mostly handwritten on paper even in a Computer Science major. Assignments cannot be typed, you'd have to handwrite everything, exams are on paper where you write pages of code.
I also occasionally code using pen an paper, when facing a tough problem. Drawing the systems out, then physically writing out the code verbatim is a great way (for me at least) to develop a picture of the problem and develop a canonical solution. In addition to copying the code over, I also clean up and copy the notes over as documentation, either as comments in code or markdown.
Actually one thing that is missig from tablets with inking support is exactly this.
For example, using Swift Playgrounds with pen instead of going through all the digital keyboard transitions, or the external keyboard.
As for the article, that is also my approach most of the time, and how I sometimes do coffee shop programming, with a paper notebook and pen in some pseudocode.
Then back at the home/office I actually try out the ideas.
I did the same 20 years ago when I was a middle schooler running my websites and wanting to add features while on holidays with my family without access to any computer.
It helped me to think about the conceptual side, but other than that I'd never do it again. I like to seperate planning and coding nowadays. Writing code on paper doesn't solve any problem for me, but I respect it if it does for OP or other people!
This reminded me of the very first _big program_ I wrote in C. My cousin showed me steps to solve a magic square [0] and asked me to write the program.
I did not have a computer at the time. So I wrote actual program on paper, ran it, debugged it mentally. When I was satisfied, next day I went to my father's office which had a computer luckily with C compiler. I typed the whole program from the paper and ran it. There was no compiler errors or anything, but it didn't print anything on screen, absolutely nothing. I was surprised because I knew it can't fail. After spending hours of checking program and reading books (internet was still a long away), I realized I had put semicolons after every single statement including `if`s and `for`s conditions, essentially short circuiting everything. Once I got rid of those extra semicolons, it ran perfectly. What a nostalgia!
In my first 'real' job when I was 18, I was hired as a programmer to work on an accountancy package for DOS. It was quite radical at the time - the concept was to present double entry bookkeeping on the screen in the same layout as it would be in a paper book. A bit like Lotus 1-2-3 but with all the accountancy stuff already built in.
Anyway, the firm I was working at only had 2 proper DOS machines, and one of those was reserved for the boss, but there were up to 3 programmers working on the software.
If the DOS machine was in-use (which was most of the time) I had to spend the day 'writing' my code on another machine (an ACT Apricot PC). This machine, although it booted into DOS, was NOT IBM compatible, so the IDE software wouldn't run. All I had was the provided Word Processor app, so I wrote in that, sometimes for days, hoping that what I was typing was working code.
I'd only know if I'd written working code once I'd transferred it via floppy disk and compiled it on the real DOS machine every few days.
Not quite the same as coding on paper, but this thread reminded me of this part of my career.
109 comments
[ 325 ms ] story [ 401 ms ] threadThere's something there, I think, but it would have been much better without the bit about bikeshedding, or reordered.
Also, a lot of the work of a programmer consists in understanding existing code. You need the computer for that.
Paper/whiteboarding is more for communication to others, in my experience
Also, I'm old enough to not have always had electronic devices, so sketching was all we had. In college, I didn't live on campus while living with my parental units an hour away. With the limited access to the computer lab, I would hand write code on paper and then transcribe. Then, right at the end of lab time, hit print so I could continue debugging by making notes on the greenbar print outs.
The problem I run into when I'm brainstorming or thinking about high-level architectural/modeling questions, is that if I start drawing something I get focused on how to represent my current idea and I stop actually developing the idea itself. And then if I change my mind, I have to go back and erase or strike things out instead of just redirecting my thought. Etc.
Usually if something is new for me or ill-defined, I take a walk or a shower and work through a rough idea of the big picture (usually realizing and iterating on some of the high-level problems) without any medium.
And then when I sit down to start seeing what that established will look like more tangibly, I usually go straight to the computer. Though I will say, I sometimes turn off type-checking when I'm just writing the idea out the first time. It can get really distracting when the code is going to be "broken" for the first 90% of the process. Once I've given it a look over and feel good about it, then I turn editor hints back on to nail it down and get it running.
Sort of like a swap file, where if the number of items gets bigger than my working memory, I dump some of them onto a sheet of paper rather than thinking about all of them at once.
I'm interested in hearing how other people approach diagrams, because I bet there are a lot of different approaches, and no one size fits all.
It works better at the phase after ideation, where I'm pretty sure I have the major ideas in place and I want to see them to make sure they make sense. But even then I prefer a digital medium because of how easy it is to delete or modify (even an eraser leaves behind a smudge, adding something to a list on paper means moving each item by hand, etc).
Use a pencil, and not a pen ;-) Much less permanent. Just knowing you can erase should make it feel less decisionish. For me it's the opposite. If it's a sketch on paper, it is so much more transitional. Once it's in code and executable, it makes me want to keep forcing things until it works. But that's what makes it fun. Each dev sees the same problem totally differently and approaches it in their own way.
The test is the problem statement, or maybe a theorem.
You then need to figure out how to solve/prove it. You can do this on paper then type it in or directly. It doesn't really matter.
When the test goes green you know you've solved it.
Use Mechanical Pencils. No leaking/drying/wastage and you always get to marvel at the ingenuity that goes into making some of these gadgets.
Plus it gives you an excuse to indulge in another collection mania :-)
See https://www.jetpens.com/blog/The-Best-Lead-Grade-For-Every-A... https://www.jetpens.com/blog/Mechanical-Pencil-Lead-Size-Com... and https://www.youtube.com/watch?v=73gZFjIAHtw
My current favourite is the classic Tombow Zoom 505 series - https://www.tombow.com/en/products/zoom_505/ Not too costly, well made, elegant and professional looking. I have the Rollerball (i.e. water-based ballpoint), Mechanical pencil and Multi-function pen all in Black.
Next up are the "Parker Jotter Originals" for EDC (https://blog.penvibe.com/parker-ballpoint-pens-ultimate-guid...). They are very affordable and hence i keep them everywhere.
Multi-function pens (which have 2 or more ballpoints and a mechanical pencil) are another must have (I limit myself to 2+1). Buy a good professional looking one (eg. Cross/Zebra/Pentel/Rotring etc.) rather than the cheap plastic ones (they look ugly).
Staedtler has a series called "Triplus" which have a triangular body (supposedly more ergonomic) - https://www.staedtler.com/intl/en/products/writing-pens/
Many of the OEMs who actually manufacture the pens but which are sold under other well-known brand names are now releasing them under their own name. Two of them are TWSBI(Taiwan) and Penac(Japan). You should check out their offerings.
If you are a Fountain Pen connoisseur, you should know that India has a large number of Artisanal Specialist Fountain Pen makers - https://www.bbc.com/news/world-asia-india-55314701 and https://www.fountainpenindia.com/
Finally, always check the offerings from Japan (Amazon.co.jp and Jetpens are your goto sites); they make some of the best and most innovative stationery.
I for some reason don't like the Parker Jotters as they are too thin for my fat fingers. Also the blue color of the ballpoint is too much on the purple side and gives me a headache. I too have one but I don't use it much but I still love it ;-). I am aware of their Gel lines but not sure whether they work for the Jotter.
>Finally, always check the offerings from Japan
I love the Japanese offerings but I don't get much in India. For eg Pentel has its factory in India but manufacturers limited set of models. I love Pentel pens btw but I am not satisfied with its offerings in India.
I am currently using Uniball Signo retractable UMN 207. Although the build and the ink is very nice it skips a lot and I am not sure whether it is because the ink is not designed for Indian weather or paper quality. I do see people having complaints with skipping but not much. I have ordered some UMN 307s and have to see how it fares.
>Many of the OEMs who actually manufacture the pens but which are sold under other well-known brand names are now releasing them under their own name. Two of them are TWSBI(Taiwan) and Penac(Japan).
I am thinking of buying the TWSBI as I really love its unique see through styling. I was thinking of purchasing a Lamy though. I am afraid to use Fountain pens as I work in harsh environments and I am not sure how it will fare but then again our ancestors were using these pens with ease. :-)
>If you are a Fountain Pen connoisseur, you should know that India has a large number of Artisanal Specialist Fountain Pen makers
Yes I am aware but the problem is I think they they import their nibs and just make the body of the pens. Somehow I don't feel like buying this Frankenstein and would love to buy the complete product if they make it.
You can find Japanese offerings on Amazon India and if needed, get it directly from Amazon Japan (i do both). You can also contact the resellers (who import from Japan and sell on Amazon India) directly for a better deal. For example, you can get the Tombow pens from https://www.foremostindia.com/
You should also check Aliexpress. I came across a rollerball pen which can be refilled like a Fountain pen which is neat.
Finally, your quote
>Yes I am aware but the problem is I think they they import their nibs and just make the body of the pens. Somehow I don't feel like buying this Frankenstein and would love to buy the complete product if they make it.
This is quite the wrong way of looking at it. These guys are very good and are optimizing their product based on their available skills. Making a nib requires metallurgy, high-precision CNC etc. which as small specialized Artisans they cannot afford to setup. So they focus on what they are good at (this is exactly similar to specialized Artisans in Germany and Japan; you find entire video series on Youtube; eg. https://www.youtube.com/watch?v=f5dekz26Kdw). For example, i have a Tombow pencil sharpener where the plastic body is made in Vietnam but the blade itself is made in Germany!. If you are a Fountain Pen guy you should definitely get one or more of this.
Finally, i should note that a lot of branded Pens are manufactured in India; eg. Parker Pens are manufactured by Luxor India and exported.
I don't think so. It is a "Parker Jotter Standard CT Ball Pen".
>You can find Japanese offerings on Amazon India and if needed, get it directly from Amazon Japan (i do both). You can also contact the resellers (who import from Japan and sell on Amazon India) directly for a better deal
Won't this be too costly due to import taxes?
>These guys are very good and are optimizing their product based on their available skills. Making a nib requires metallurgy, high-precision CNC etc. which as small specialized Artisans they cannot afford to setup.
I think Ratnam makes the complete product. I must say that I am not much into Artisanal pens though. Similarly I am not much into funky anime type colored pens from Japan. :-)
>Finally, i should note that a lot of branded Pens are manufactured in India; eg. Parker Pens are manufactured by Luxor India and exported.
I don't like Luxor very much. I think there are quality control issues with the Parker pens as there is a lot of rattling in their jotter pens. I researched and found that it is not universal and was pretty pissed off as the Jotters are not cheap. Another reseller is Linc who are resellers for Uniball and they don't care about what they are selling. Similarly Pentel has a measly collection even though they have a manufacturing plant in Gujarat.
In my school days I used to use a Hero Fountain pen (Currently Shanghai Hero group) which was pretty good and my daily driver. My mother still had her beautiful Pilot pen from the 70s which I started to use later. I also sometimes used to use my classmates Butterfly pens too. I bought a Hero fountain pen in 2008 and it was horrible. Not sure what happened to it.
One of the advantages— perhaps the main advantage — is that the notepad doesn’t have an internet connection.
We bought the books, wrote the BASIC code and rewrote it many times until we thought it was good.
Once the computer came though, all that went out the window. But to this day, my desk is covered in notebooks that help me visualize problems before writing any code.
I sketch out UI. Design database schemas. Draw data flow diagrams and end up with many, many, many notebooks finished up every week. I don't know if it makes me any better as a developer, but whenever I do it, I feel more confident approaching the computer and working on a solution.
One of them graduated from IISC, Top rank holder in all-India entrance test for it, is at top position in a leading SW company abroad and another runs a SW company in our city with about ~ 100 employees for 25 years (he's content with the scale); Many of his ex. employees are at top positions in FAANG.
I guess the story would be same for many from GenX who have made themselves a great career in IT but couldn't afford a computer when they were studying.
I personally really enjoy pen because it makes you own your mistakes.
[1] https://www.cs.utexas.edu/~EWD/
I think a lot of people here are not getting the gist behind the use of pen and paper; so let me try to summarize it;
* They do not limit the concrete expression of any concept/thought that you might have. You can use text, symbols, invent new symbols, connect them in any fashion you choose etc. etc. They are free form and become an extension of your mind. See also the book; The Body Has a Mind of Its Own: How Body Maps in Your Brain Help You Do (Almost) Everything Better.
* They force you to slow down your thoughts i.e. still your chaotic mind and help focus on the problem and its various aspects. This is invaluable in today's world filled with distractions. The books by Cal Newport are applicable here.
* If you choose to make your notes public, it adds another layer of discipline to really understand the subject matter since you have to anticipate possible objections and have the answers ready.
* Finally, they help clear your mind of the inessentials allowing you to ruminate and manipulate the essentials more effectively. Yet ancillary data is always available as needed.
If you look at History, all the greats wrote prodigiously. I firmly believe that it was one of the defining factors which directly led to their eminence. I was first inspired by the Notebooks of Leonardo Da Vinci (get the 2-vol large prints by Dover) before i started noticing the pattern.
PS: I read somewhere that Dijkstra wrote one of the first Operating Systems; The "THE" Operating System by hand on paper!
Edit:
This line resonated with me:
> Maybe someday I’ll be able to handwrite code on an e-Ink device and then run it.
Are there successful projects for pen-based programming? I've read about Grail as a historical footnote, using hand-drawn flow charts: https://wiki.c2.com/?GrailSystem
I'd also be remiss to not mention Ken Perlin's Chalktalk project, though that's mostly a presentation system as it stands: https://github.com/kenperlin/chalktalk
These are both largely graphical and gestural, with a good number of low-stroke symbols instead of handwritten strings for the most part.
On a similar note as the author, I enjoy stepping away from the screen to code, though it's mostly for problems I'm stuck on. There's been many times where I've been lying in bed thinking about a problem and I suddenly think up a possible solution in my head and then run to my computer to type it out to see if it resolves the issue.
Is time we bring back Static web page. We have Modern MultiCore CPU and SSD. Surely 99% of personal webpage shouldn't require a call to DB.
Edit: Oh interesting this is from the oringal author of Sequel.
You may be doing some abstractions/pseudo code on paper but you're not coding. You're planning.
There's nothing wrong with this! I think it's a great way to operate. But it's less sexy to say "How I Plan: Pen and Paper" then to conflate it with coding.
Everyone does planning. Some people do it on-the-fly while coding. Some people do it in their head. Some people write it down.
> I opened my laptop, created a new Github repository, typed in the code, added some tests and wrote the README. It was probably all done in 4 or 5 hours of concentrated work.
Means handwritten code verbatim went into the repo. The focus on iteration is great - it would be unusual to stop at this point.
But if we say the written word is canon, my response is that's inefficient. It is indeed the planning that is most valuable when putting pen to paper.
It actually helped make things stick better, after initially adjusting to it.
Afterwards, I would end up typing code more deliberately, and found myself tapping delete far fewer times.
Very similar experience to learning drafting-by-hand before CAD.
feel bad for the T/As that had to grade all those exams.
The author is conflating coding with solution planning in a pretty minor way - you're more seriously conflating coding with solution building.
Architects do a similar thing, they visualize in their heads and on paper, but then they also actually build 3D small-scale prototypes to get feedback on their design.
So I would say that coding can also be an important part of the design process. It is not just transliterating what's in your head to code-files on the computer, it can help improve the design which is in your brain.
I think it’s always true that there is some time spent figuring out what problem is being solved, what needs to be built to solve the problem, building something, and making sure that it solves the original problem.
In mechanical or electronics it tends to be called manufacturing instead of development. In civil engineering or architecture it tends to be called construction instead of development. I think the difference in creating software is that one person can do all phases. They can even do the phases without formally documenting anything. The phases can be much shorter and iterated on much quicker in some software projects. I think when the software projects become larger and require more developers that they tend to have a more clear demarcation between phases and use more formality in documentation.
I think it would be more beneficial to the software industry if everyone was working with similar enough terminology that discussions don’t end up revolving around who is operating under what definition and which definition is best. But at the end of the day that’s just my opinion.
I don't see how some solutions not requiring code means that coding is not valuable, as some solutions evidently do require code.
When the solution requires code, the code is the solution, whether it's written in pseudo code or a language. I don't think there is a line separating the two. Just like language is thought.
Your "deploying solutions" could be replaced with "deploying code" (whether created in house or third party).
If your solution depends on code, then the quality of that code will also be important, which will include aesthetics, design, readability, tests.
In the long run, this is valuable, as you can't regularly and reliably ship the solution, unless you're confident it still works.
So if you're a programmer then you're in the business of building software solutions which are generally built via writing code or script of some sort.
If the problem is best solved via a method other than writing software, then that's great. Not every problem needs software. Not every problem even needs solving either.
If however the problem does need a software solution then it's obvious that you should make sure you actually understand the problem so that you actually solve it.
I guess I just don't see how coding isn't equivalent to solution building unless what you call coding I call typing. For me thinking, researching, investigating, designing, engineering, planning, and even just "sleeping on it" are all part of the coding process.
I suppose that if the purpose of your coding is to learn or play then you might not be building a solution.
Is this just semantics or am I missing something?
I don't think so, or perhaps expressed myself poorly. Planning is a critical part of solution building. Coding is putting the pieces together.
Unless you're absolutely winging it, you're mostly doing planning and then execution. My argument is the planning - the most important part of solution building - is what's being done on paper.
Since it's against the rules to question whether you've read the article, but people on here call each other liars all the time, I am forced to ask you why you are lying about what the article says.
Why are you lying about what the article says?
For example, using Swift Playgrounds with pen instead of going through all the digital keyboard transitions, or the external keyboard.
As for the article, that is also my approach most of the time, and how I sometimes do coffee shop programming, with a paper notebook and pen in some pseudocode.
Then back at the home/office I actually try out the ideas.
It helped me to think about the conceptual side, but other than that I'd never do it again. I like to seperate planning and coding nowadays. Writing code on paper doesn't solve any problem for me, but I respect it if it does for OP or other people!
I did not have a computer at the time. So I wrote actual program on paper, ran it, debugged it mentally. When I was satisfied, next day I went to my father's office which had a computer luckily with C compiler. I typed the whole program from the paper and ran it. There was no compiler errors or anything, but it didn't print anything on screen, absolutely nothing. I was surprised because I knew it can't fail. After spending hours of checking program and reading books (internet was still a long away), I realized I had put semicolons after every single statement including `if`s and `for`s conditions, essentially short circuiting everything. Once I got rid of those extra semicolons, it ran perfectly. What a nostalgia!
[0] https://en.wikipedia.org/wiki/Magic_square
Anyway, the firm I was working at only had 2 proper DOS machines, and one of those was reserved for the boss, but there were up to 3 programmers working on the software.
If the DOS machine was in-use (which was most of the time) I had to spend the day 'writing' my code on another machine (an ACT Apricot PC). This machine, although it booted into DOS, was NOT IBM compatible, so the IDE software wouldn't run. All I had was the provided Word Processor app, so I wrote in that, sometimes for days, hoping that what I was typing was working code.
I'd only know if I'd written working code once I'd transferred it via floppy disk and compiled it on the real DOS machine every few days.
Not quite the same as coding on paper, but this thread reminded me of this part of my career.