3 ms·
And using UML selectively and intentionally can build the habit of thinking before coding. It's a mental exercise, much like test-driven development or writing
by voxleone 1y ago
And using UML selectively and intentionally can build the habit of thinking before coding. It's a mental exercise, much like test-driven development or writing pseudocode, that strengthens your design intuition.
- flohofwoe 1y agoThe question is if (too much) upfront planning is actually better. IME it's more useful to treat a source file (or new project) like a sketchbook, you start with an empty sheet of paper but already have a rough idea what you want, then you quickly sketch out the outlines, try out different ideas, explore different solutions (all without going into too much detail yet), you step through the code, explore some different paths to get an idea what "feels right", delete things, shuffle them around, rewrite them and slowly filling out the details and that way incrementally get towards the first working version. Which such an approach of incremental "micro-feedback-loops" you already eliminated a lot of dead ends that will appear anyway despite the best plans - but identifying such dead ends early is much better than late. This incremental approach also forces you to keep the code small, tidy and malleable. The planning stage basically already happens in source code, and it's not one long planning stage, but many micro-planning-stages. ...this is also my problem with the current state of LLMs, they're pretty good at creating a first initial sketch from a very general problem statement (but only for things that have been done thousands of times by other people - but that's a different issue...) - but the more you'll need to go into the details and discover and fix problems in your initial 'mental design' (e.g. discovering what you actually wanted in the first place), the more the differences to traditional programming disappear, and at some tipping point it gets even more complex because you need to steer the LLM with a language (the human language) that simply isn't useful enough for detailed problem descriptions - that's why lawyers, mathematicians, engineers and scientists all invented their own precise 'DSLs'. After a few iterations your prompts need to be just as detailed as writing source code in the first place - so what's the point of writing prompts in human language again? I feel like productivity could be improved much more by improving programming tools (yeah - boring old-school incremental maintenance work) instead of betting on some weird AI future which will just move the focus from writing source code to writing human-language prompts (which IMHO is a definitive step backwards because human language lacks precision - and adding that precision is how you end up with programming languages). Why are editing, compilation and debugging/testing still separate steps, why do debuggers still have those 60s style bare variable panels instead of realtime visualizations of the internal program state? Why do I still need to wait for a build to finish? Why is version control still such a PITA to work with? Instead everybody is jumping on the AI hype train while everything around them is crumbling into a post-apocalyptic wasteland.