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.
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!
HN old-timers probably remember 'edw519, who sadly isn't commenting much anymore. One of the things he is known for is for extensive use of pen/pencil and paper in his programming work - the second part of his day involves printing out listings of whatever code he's working on, and working on them away from the computer.
There's a collection of edw519's best comments here: http://static.v25media.com/edw519_mod.html - CTRL+F "paper" will show many answers in which he talks about how he works with it.
Thanks TeMPOral for the trip down memory lane. I remember you through all those years.
It's true that I don't comment much anymore, but remember, when someone who used to comment with so much energy before slows down, it's probably because they're so busy with the stuff that made them comment in the first place.
When I said that 'you sadly aren't commenting much anymore' I meant that in a selfish sense - it's sad to me, because I enjoyed your comments over the years. I've guessed you must be spending your time on more interesting and rewarding things.
It's fun to see someone else that does this! I also write code with pen and paper. Mainly for work, but I have good memories of a holiday with a notepad and The Little Schemer (with a long till receipt to cover up the answers column).
Similarly I sometimes code review by printing out diffs and writing on them.
I like the tactile side of writing, and the spatial freedom. Also I just find it easier to think away from a screen somehow -- coding on a computer is still my majority case, and it's essential where it's the type of work that involves stitching things together. But for algorithm or code-design style work, if I get stuck I write it down.
One theory I have is that because I have a very spatial/location-sensitive kind of memory, scrolling on a screen messes with my internal mental map of where things are.
I mean that if I'm designing something or trying to understand someone's code, my working memory built up of the things that I'm reading or writing down is linked to where I read or wrote it, and I think a single screen space in which anything and everything can appear messes with that and makes my brain have to work harder to remap things.
I can forget almost anything no matter how obvious, but if it's linked to a location or is spacial then my recall is spot on. I can't tell you anything about 90% of my education but could give you exact waypoints for a 3 day walk I did over 15 years ago.
I've tried harnessing this ability with the 'mind-palace" techniques where information is associated with a visualised place. I worked at a large outdoor store for a few years with a huge stockroom and used that as my base. As I was learning programming I assigned topics to sections of the stock room and related concepts with specific products. Sounds nutty but it did seem to work (I can still recall all this information).
Remembering things this way fell by the wayside though as it requires very intentional "remembering" in the first instance. It's exactly like filing — you have to do it upfront. I never used it enough that this became second nature.
I do write code on paper though, but I quickly realised that writing in a journal is suboptimal for me. When I studied design we were encouraged to take notes on loose-leaf paper both to reduce the "preciousness" that comes with bound notebooks and so that we could reorder pages but also spread it out for a high-level view. For this reason my preference is writing code on index cards where each card is a data structure or function which then get grouped into modules (thinking Elixir here).
Despite this preference I tend to just use a notebook for scribbles and "working memory" notes because I'm prone to losing cards. I've toyed with the idea of a huge blackboard and post-it notes in my office before which I may look into again soon.
Scheme/Lisp seems to be a great representation for this, the author suggests diagrams and text, which I assume is optimal for most things, but sometimes it's helpful to write pseudo-code and it seems to me that S-expressions are almost friction less in that regard, especially since it provides visual structure without having to (re-)format code too much, but also because of the minimal syntax.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
I accidently discovered the benefits of writing code on pencil and paper some years ago when I was looking for a career change. I picked up a C book that had exercises in it but only had time to go through the book during my commute on the metro. Because I worked in a SCIF I couldn't take any electronics with me to work. So I would read a section the night before, go to bed, and churn out the lab solutions in a notebook on the metro. At the time I thought these circumstances were slowing my progress. Once my circumstances changed and I had the time to do everything with two monitors and every IDE on the internet, I was bogged down.
I am not a developer, but occassionally need to write code. I always go to the paper first now.
When I was a student I identified the keyboard as one of my greatest impediments to good programming. Something about being in front of one before doing the 'real' work of thinking through the problem was just too tempting, and I'd ignore the problem solving and just start typing.
Terse languages like J and K also make good candidates for writing code using pen and paper. Hillel Wayne has an interesting blog post detailing the very same note.
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'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.
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.
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..
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.
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.
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 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 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'm a hybrid, I have piles of 5mm pads/pens but I use them as a local memory store more than a pure design tool.
I also have an ipad/pencil with the excellent notability app (excellent because it gives me an infinite grid page) for jotting notes/things I need to follow up on.
I tried keeping that stuff in a text file but there is something about writing it down on the ipad that means I rarely have to actually look it up, it sticks in my memory better and if I do forget what I had to do I rarely forget that I had something to do and can just look it up when we need to.
It's pretty cool how the comments are divided between "I write code on paper/I used to write code on paper" and "Nobody could ever write code on paper, she must be speaking metaphorically." It's kind of like China Mieville's "The City and the City": somehow these two populations in the same place don't see each other at all, or they pretend not to, in order to avoid conflict.
I have an easier time writing code on paper than on a computer when it's "algorithmic" and its problems are internally generated, or when it's in a domain I already understand really well. I wrote a Soma cube in OpenSCAD once in a text editor on an internetless iPhone, which is more or less the same thing; Naomi Wu mentions that this is one of the benefits of OpenSCAD for people in poor countries, where they maybe don't have access to sit in front of FreeCAD or Blender all day, but they can totally type text on their cellphone while they're on the bus. Or write it on paper, maybe, but that takes two hands.
On the other hand, I also write a fair bit of code where the relevant unknowns are things like "What kind of user interaction will feel responsive?" and "What will this API do if I invoke it with these arguments?" and "How many public recursive DNS resolvers are there on the internet?", which are not things I can find out by thinking and writing things on paper.
> When you write code on paper, you have no way to see if your code works. Maybe someday I’ll be able to handwrite code on an e-Ink device and then run it.
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!
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 used actual toilet paper to write programs on for the first year or two after I started programming. (I just had no computer of my own.)
This was not the kind of toilet paper you would see nowadays, though. It was not in a roll, but a deck of precut pieces, and they were not soft at all. One side was glossy, and the other - rough. The glossy side was perfect for writing. It was almost like a notebook, only cheaper.
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.
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've always used writing to sketch out informal specs or high-level architectural things. I've always heard about people writing code by hand on paper. I gave it more of a shot after reading, Algebra Driven Design. It's a powerful technique.
While I often prefer the interactive feedback of a proof assistant or model checker I find spending time away from the screen and thinking on paper to be very relaxing and helps me with, "connecting the dots," so to speak. I tend to get a very narrow focus on the problem at hand when I'm at the computer.
I too hope to one day be able to write code by hand on my RM2. I have hacked a basic editor into an RM1 but it's slow going.
My Algorithms professor in uni used to say something like "back in my days, we only got one shot at completing our exercise lists, because you had to physically walk down to the computer room and hand over your program in a punch card, and then as a student you were low priority in the compilation queue, so the whole thing could take weeks."
I had several mostly pen and paper courses because the professors preferred that to lab assignments. This was 2009.
They have a point. If you don't have an instantaneuos REPL, you'll probably think harder about what you are writing.
I always feel boxed in inside an IDE -- Why can you not attach images inside IDEs? diagrams of what you want to do...
I like doing this in notion -- here you can write code with the syntax highlighting and attach all sorts of stuff to the document -- once you've crystalized exactly what you want to build, you can fireup your IDE and get to work.
I think it ties with the theme -- A programmers work is not to type things -- the main input is thoughts and ideas that can be interpreted by a computer to do correct things. A notebook helps with the thoughts and ideas part.
You should check out Julia's built in notebooks. It's basically a script / source file with comments that get rendered as markdown, which means you can add images and it is all rendered nicely in editors that support it. It's better than jupyter notebooks, because they're not big blobs of Json that can only be edited efficiently in the rendered environment, but not as plain text.
I think you're referring to Pluto.jl [1] notebooks? It's an external package, not built in with Julia, but yes it's very nice to just be able to open a notebook in any editor and plays much nicer with version control too. (Or maybe you mean Weave.jl [2] files, though I believe they're the other way around, Markdown with source code sections in it.)
How about third party libraries? I mean you can remember the APIs or you write a placeholder that says this function will be provided by some third party libs.
Or what you work on is pure vanilla code?
Writing code on paper doesn't work very well for APIs you're not very familiar with. But she apparently knows the Arguments API well enough to write out calls to it without rereading the manual.
This paper talks about the history behind how "writing" code came to mean "typing" it. Originally, the very first programming notations were handwritten. Interestingly, they weren't called "languages" either, until FORTRAN introduced the typewriter as semi-direct input. See here: https://dl.acm.org/doi/abs/10.1145/3313831.3376731
I sat an exam in high school where we had to hand write code for... Either a Mandelbrot set generator or some prime search thing, can't remember.
But it was a simple algorithm and it didn't specify a language so I wrote it in 386 assembler. I think that to this day is the only program I wrote by hand, and I know it compiled and ran correctly as they made me type it and execute it (only for fun they knew I knew what I was doing)
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.
I often write code outlines on paper, to focus on logic instead of syntax. It is often my starting point. It helps me stay in the logic flow, without any interruption from the IDE every other second. Later, when ready to type the code in, I pay attention to syntax knowing the logic has been worked out. More efficient for me.
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.
When I studied computing at school we would hand write our Fortran code on paper. After handing it in it was sent away somewhere and an operator would type it in and run it. Two weeks later we would get the result (assuming no typos).
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.
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.
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.