Hacker News Reader

Comment by xnorswap | Hacker News Reader

I couldn't disagree more.

If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.

Your IDE isn't suitable for prototyping, or something else is going wrong.

I'm not suggesting that nothing in the planning phase should be white-boarded, but pen is the wrong medium for code.

You should have a tool where you can fire up your tooling and be writing the same thing you would write on paper, but with autocompletion, error feedback and browsable interactive output.

In my experience that's far more appropriate an environment for rapidly getting something down and working through the problem.

By all means, start with pen and paper to get a feel for the problem domain, but that process should stop short of actual code, and this article doesn't really sell me on the benefits.

I'd rather test my assumptions in something like LinqPad, where I'll get real feedback not just a "feeling" about what I've written.

View on HN

Honestly, if anything I'm trying to do is sufficiently complex, I reach for pen and paper and use drawings, abstract ideas to have a better idea of what I'm going to code.

Actually, this way you catch a lot of poor design decisions that you would otherwise fall into. If starting out with code, I might attempt to "fix" poor design through hacks due to the "sunk time fallacy" of code already written, that kinda works, but isn't maintainable.

Honestly, no "tool" on a computer would let me print my imagination as easily as pen and paper. Perhaps a drawing tablet, but that's an additional thing I would need to plug into my PC.

> If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.

Oh bull. At the level of thinking where you’d pull out pen and paper, ALL digital tooling sucks. Not one single solitary tool can beat pen and paper at that level. Not one.

Rather than "bull", I suspect we're already in agreement, given your statement, "At the level of thinking where you’d pull out pen and paper".

We appear to agree there's a place for pen & paper, and we appear to agree that's a different level to coding implementation.

Writing down code, complete with correct syntax, parentheses, indentation, etc, as the article wants, is not in my opinion that level.

At that level, the tooling does not suck.

So yes, I agree, "At the level" where pen & paper shines it should be used.

That level is not writing correct code, unless you can convince me otherwise?

For myself by writing prototypic code correctly with pen; not only does it keep my vision straight, it also gives myself clarity and a sense of sanity of say, what that function does.

With the hard evidence you can then refer back to. So, when you are ready to expand your design you already have the foundation on page.

It acts as a pillar to the psuedo code that comes with design later on. If that is the going to be foundation to that function, it might as well be written correctly on paper.

I don’t know if it’s from Calm Technology, but here something that i read about recently: Don’t make humans act like a computer and don’t make the computer act like a human.

The first part is something I believe in this case. It’s ok to think with pen and paper (and I do when trying to find an algorithm) But I stop short of implementation details, instead typing out code. Why? Because text editors is much more flexible in this particular case (live programming environment, REPLs, or a quick code-compile-run cycle are much more useful)

And the second part is why I don’t like LLMs for code generation. Snippets are more deterministic. I’m ok with it for suggestions of ideas I can explore (in books, not with the LLM)

Oddly, for me the feedback of the computer is too fast for thinking. I like being able to write a bit before thinking about some details.

More, I find that forcing myself to run the code in my head is a good idea.

That all said, I don't do the paper thing often. Really only when thinking at a level other than the symbolic of text. Some system diagrams. Sometimes numeric. I suspect if I got good at Mathematica, I'd do more numeric thinking there.

If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.

Or maybe it's horses for courses?

Personally I found the idea of going beyond prototyping on paper as a rule not for me, though there are sometimes final snippets reveal themselves better away from the screen when I'm stuck in the mud on something.

My point is though that we really ought to allow others to find their own way and what is best for them rather than dismissing it so emphatically because we don't personally get it.

You can take as read that all my posts are prefixed with "In my opinion". I find it unnecessary to type that out on every post.

Taking a format that only a computer can interpret, code, and choosing to write it down on a medium a computer can't read, hand-writing, is not typically a productive exercise.

Even in interviews I'd rather hand a candidate a laptop.

There are more worthwhile things to hand-write, such as sequence diagrams, and there are more worthwhile places to write code, such as an IDE.

If someone is finding it easier to write code on paper than in an IDE, I'd rather not ignore that signal and try to discover why their IDE is proving such an impediment.

Maybe it takes 10 minutes to start up, maybe it throws up so many errors for each syntax mistake that it's distracting and hard to see the wood for the trees. Maybe it doesn't actually produce useful output. Maybe it doesn't have real time debugging and step-through.

Who knows, but something is causing it to be mentally easier to write down the same code on paper than the IDE, and that's not something that should be ignored, that's something that should be fixed.

I personally tend to think better when I'm away from the computer.

Coding on the IDE helps me to experiment and quickly put something together that works.

But thinking while writing things down or while walking is a slower process, so it helps me focus on nothing but the problem obvious edge cases, different solution designs, etc...

So by thinking about the code away from the IDE first, then by polishing my ideas on the IDE, I usually end up with higher quality code.

But since it's less fun to do things that way, I just tend to do everything on my IDE.

You can take as read that all my posts are prefixed with "In my opinion". I find it unnecessary to type that out on every post.

Its obviously a given - except where people are commenting in a way that indicates they are expressing the one true way, as you did, and have done again.

The OP's way is not for me, but I'm ok with it being for them.

I agree that if there is a problem in their process or workflow that is influencing an inferior (for them) approach it is better to try to help them fix it.

> If someone is finding it easier to write code on paper than in an IDE,

The post isn't about writing code on paper, but about the planing and ideas collection before writing effective code.

> write down the same code on paper than the IDE,

No, pseudo-code and notes and flowcharts aren't the code (maybe the later on some visual language environment.) You're missing the whole point, sorry.

This makes sense to me if the problem I'm solving simply devolves to code and I want as short a path as possible to completing it. I really don't see that much anymore, other than basic bug fixes.

Not every problem I'm solving is just a hunt for the code implementation. I like to reason about solutions beyond the syntax. I use pen and paper a lot, including for code, and I'll use shorthand to represent longer-form code blocks. I find that approach better because I can hide the noise that code blocks can introduce in an IDE. I want code to support my solution -- not a solution to fit into code. IDEs and frameworks can have that affect on people, in my experience.

As with this comment and the one preceding it, your mileage may vary.

It's like you and many people didn't read and understand the post.

> but pen is the wrong medium for code.

Pen & Paper is really excellent for many people, maybe not you but it's fine some others. You may use an electronic device (some people are using Remarkable and alikes) or chalk and black board, or MindMapping app; the key idea is to first forethink and analyse the problem before diving into coding.

> your tooling and be writing the same thing you would write on paper, but with autocompletion, error feedback and browsable interactive output.

What kind of tooling do you use for pseudo-code (not a real language, but textual informal prose) with that features?

I agree that there's not much point in writing actual literal semantically correct code on a piece of paper, but I don't think that's at all the point of the article. The author talks about understanding the problem space, getting their ideas organized, and (if I may charitably interpret the article a bit) even go as far as scratching out some ideas of what the code might look like.

You haven't mentioned pseudocode ?

Pseudocode isn't coding, but sufficiently advanced pseudocode is indistinguishable from Python.

Regardless, I don't see why the parent would have necessarily mentioned pseudocode for any reason?

Because that's a huge part of what the article talks about ?

(Also, even Python is at more risk of funneling you in some direction that might be suboptimal, at least more than pseudocode.)

Reply on news.ycombinator.com