I have spent some time over the past few years learning how to code a bit, simply out of curiosity and as a hobby. In the past two years LLMs have allowed me to start actually producing code (usually python or bash scripts) to do useful tasks for work (strategy type role) or personal use but whenever I try to push a bit more towards a fuller solution I inevitably end up with code I struggle to understand (and rarely works as I iterate with the LLM to add or modify various aspects of it).<p>Are there things HN would recommend i add to my prompts to produce code that’s more easily readable and modifiable by a beginner tinkerer? I usually ask for heavy commenting, docstrings, and to write in a way a beginner could read the code; but are there other/better snippets to insert in my prompts to tailor the output to my needs.
What about asking it to always use pure functions. In theory they are stateless, easier to test, and you can also have the LLM write the tests which should illustrate what arguments the function should have and what the expected output should be.<p>This usually lets you build a cleaner mental model of what is happening, and then you can think clearer about composition of functions where each building block is confirmed to be working because you have tests.<p>At least that’s how I would use an LLM to help me.<p>In general though it might be worth spending time on the architecture of whatever you are building as well, this requires thinking on your part rather than a fancy prompt, but you can also use the LLM to help bounce ideas off and suggest common architectures.<p>For example in Python you can get really far with just pure functions and the majority of classes you use being dataclasses and minimal methods /minimal OOP stuff to model your domain and data shapes.
Generally, to learn anything, you need a learning framework that focuses on<p>* structured detail - ie how things connect to other things. For example, when you use a list comprehension in python, what is the equivalent for loop syntax?<p>* differentiability - i.e what happens if you do something different. For example, if you don't close a file descriptor, what happens? If you use string instead of bytes, what happens?<p>If you try to learn with a "how to do stuff" approach, you end up with having an internal lookup map where you can't reason through code if the knowledge is not in the map.<p>So for prompts, asking the LLMs those style questions goes far.