Type out the code
92 points by Gabriella439
92 points by Gabriella439
I strongly second all of this.
when you complete an exercise delete what you did and do it again, but try to use your memory. If you get stuck then look at the exercise for clues, but try your best to recreate what you just did from memory
There's precious little on this world more important than this.
I think one addition that's worth making is that you should really type out your commit messages and docs. Like sure programmers hate writing this stuff, so it's tempting to go "aha I'll just have the LLM write it"...but writing it yourself forces you to confront the UX and implementation decisions in a single place. "Oh to do X you pass -Y...wait hmm is that the ideal way to do it" "This fixes X by doing Y...huh but maybe doing Z instead could also work."
Yeah, I like to call this "tutorial-driven development" where you write the tutorial and work backwards from the desired user experience instead of thinking about the user-experience after the fact.
Yes! I encountered this issue yesterday where I was assigned a pull request with an LLM-generated wall of text that didn't tell me why the change was needed, but did go into excruciatingly worthless detail as to what changed. The attached Linear issue was the same.
I'm trying to impress upon my team that we have to do some actual thinking so we can maintain this codebase.
Fixing vibecoded trash that you don't understand is actually a good way to learn, you get a whole lot of typing in and the space you do it in isn't a vacuum.
recently i vibe coded something that sorta worked but not very well and the code was so bad. took it as an opportunity to rewrite it by hand and re-learn some of the programming skills that have been atrophying for me over the last 8 months. i feel rly good about the rewrite and it actually works better too. the llm is still helpful for explaining or getting me unstuck. it feels much better to know the whole codebase.
To illustrate what I mean, I recently audited an LLM prompt and stumbled across this:
Never suggest external tools or alternatives that aren't part of the skills listed above. If a task requires capabilities beyond the available skills, say so.
This is the sort of prompt that I would read as functionally inarticulate: it sounds sensible if you don't read closely but when you do you might notice the prompt is actually giving the model two diametrically opposed instructions.
At the risk of proving myself functionally inarticulate, how are these opposed? Saying "I can't do this with the skills you provided" is consistent with both instructions. If the last sentence was "if the task requires ... skills, say which ones you need" then they'd be opposed, but as it stands I don't see the inconsistency.
In my view, your suggested response ("I can't do this with the skills you provided") isn't consistent with the second instruction.
My read of the second sentence is that it is instructing the model to positively affirm (constructively) the existence of required external tools/alternatives, rather than implying that they exist by negation (non-constructively).
I think you are right but likely writer of the prompt actually did intend the llm to say what it needed not just "I'm sorry, I need another skill which I know about but am not permitted to tell you." But perhaps they really did mean exactly what they said!
"I find that functionally inarticulate people, almost to a person, also struggle to spell or form grammatically correct sentences on their own because you can't separate the small stuff from the big stuff: when you skimp on getting details correct that bleeds into everything you do and you begin to get the big picture wrong, too."
This reveals a pretty rough bias against people with dyslexia or just people who think differently than you seem to consider correct. Granted I don't think you are necessarily saying the inverse is true (that an inability to spell or form grammatically correct sentences implies that a person is functionally inarticulate) but its an intolerant thing to say either way.
To make a more constructive argument, consider node editors. Node based systems have a lot of problems in their current incarnations but one of the things they can do if built well is filter out classes of syntax errors because they control how the program is authored. Some classes of errors can't be made by construction because the tool won't let you say those things. As an example, if a node takes a string, you can't pass a number. Not because it enforces the constraint at build or heaven forbid runtime, but because you can't say that a number goes there. It only takes strings by construction. Thats a simple example, but other errors such as incorrect loop bounds, wrong argument counts, or some equivalent to parenthesis imbalance could be made impossible to get wrong.
I don't think writing software with a tool that imposes a constraint by construction means you don't understand the constraint. It just means that you don't have to worry about accidentally typing the wrong thing for this class of error. And being frustrated when the tool doesn't take care of the detail of a syntax (like ensuring you have the right number of curly braces in a function to close it out or the right indent level for a part of the logic) doesn't imply that you don't understand why you need to care about the syntax.
I highlight node systems as an example that pulls the llm fire-and-forget-ness/brain off vibe coding out. It isolates the syntax part without the other (in my opinion) more damaging pieces of modern llm usage. Without the llms I think the focus on syntax sorta falls apart a bit.
I agree with the rest of the post. I just think keying on syntax as some underlying indicator of someones ability to understand or write good code is very misguided.
You're correct that I am not necessarily saying the inverse is true. I'm not claiming that the inability to spell or form grammatically correct sentences implies that a person is functionally inarticulate.
I understand that you're providing this feedback in generosity and good faith, though, and I don't want to come across as defensive. I think I did make an effort to word things in such a way as to not make the intolerant claim you're flagging, but I'm open to alternative wordings/presentations of the same material.
I don't think I would want to delete the point altogether, though. I would still like to preserve the overall thrust of what I'm saying, which is that spelling and grammar are usually the first things to go when a person begins experientially avoiding mental discomfort. Perhaps there is a way I can adjust the claim so that you don't feel like people with dyslexia are caught in the crossfire.
Yeah I mean that makes sense. My only point is that by keying in on spelling/grammar as an indicator for this type of behavior you necessarily will catch people who would otherwise not get flagged. Its just a dangerous heuristic is all.
To me it makes sense to look for evidence of experientially avoiding mental discomfort when it results in mistakes that sorta matter rather than for the things that dont.
Like I said, I think your main argument is really well made! And it stands without pointing at spelling mistakes as one of the things to practice avoiding. Obviously thats just my opinion, you do you <3
I've worked with people who have dyslexia and the quality of their text/grammar errors is fundamentally different from that produced by people who can't think clearly enough to write complete sentences.
To avoid calling out any specific human, here's a snippet of LLM-generated text which roughly matches what I've seen in real life from competent engineers with dyslexia if they had to use a text editor without spell-checking:
# This endpiont rigesters the target roadruner and trggers the gravity deployment.
# Wile the amvil falls, the sistem bocks any subsequent requests to prevent bounsing.
And here's LLM-generated text which resembles that produced by a project manager that, as my coworker said, "types like fuckin' Keyboard Cat".
# calc hw mny rockets 2 order 4 da week ur gonna need 2 chek
# da inventry 1st bcuz if u dont da coyote wont b able 2 catch
# roadrunner so pls dont 4get 2 run it evry monday ok thx
You do not want to depend on code written by someone who writes like the second snippet.
For example, if you have difficulty balancing parentheses I'd begin to wonder how fluently you can connect someone else's logical premise with their conclusion.
Ha ha. Hey, wait a minute!
In my defense, sometimes functions get very jumbo-sized.
I mean this is how we literally used to do it - programs came as BASIC in a magazine and you typed them in yourself.
Similarly, people who struggle with syntax often struggle with abstract thought.
Overall it's a sensible argument, I think it diminishes that people learn and reason in different ways. Some people are extremely visual for example - diagrams, pictures, flowcharts. Even if this is their internal model.
I have this overall feeling that when I have a clear concept of what I'm doing, the syntax+structure just flows. In fact, it's a signal I've learned to connect with. If I'm struggling with the syntax then it's rarely a skill issue - it's my mental model is incomplete.
Others are the reverse! The broader syntax and structure helps them understand the problem.
Anyway, I'm writing like I disagree - I don't. But I do think this overreaches in those areas.
I really like this advice. When I’m learning a new programming language my preferred way of doing it is in a text editor without syntax highlighting and code completion. I type the program, try to compile it, see the error message, fix and iterate.
As an any person, I’m usually biased by previous programming experiences, so sometimes I make assumptions and find out they work or they don’t while compiling.
I actually do all my programming this way and I keep learning new things. I usually don’t have to look up the documentation a lot after some time with the language. I know the std libraries of the languages I pretty well.
I should also mention that I read through the standard library documentation [and code] of the PLs to fine-tune my intuition.
Side note: I really enjoy programming. I enjoy reading and understanding things about computers. I like giving precise instructions to the machine and see it achieve the goal I set. I do not understand why people offload such joyful activity to AIs. The best decision in my life was to study computer science. Computers are such amazing and complex creatures. Dedicating a lifetime to learning about them is something I really look forward to and have enjoyed so far.