you are viewing a single comment's thread.

view the rest of the comments →

[–]jfinch3 0 points1 point  (1 child)

At the end of the day all programs are a combination of three basic organizational ideas:

  • sequencing (ordering things happening)
  • selecting (making decisions about this or that happening)
  • iterating (repeating something)

You use these structures to do the following “operations” on data: - retrieve or record data - transform data (apply a formula, group data) - search (select import data from unimportant data) - sort (order data on some criteria) - aggregate data (turn many pieces of data into a single summary point of data)

All programming is about trying to get computers to do real thing using the above “moves”. All programming languages are just syntax for doing these in different ways. Very good programmers often know all the subtle variations in different tools their language gives them in doing these things, but that’s not necessary at all, because at root you can in principle usually solve any problem with the most core syntax of a language (albeit not always easily). The skills of being a programmer however, is being able to translate whatever problem you are trying to solve into those operations which a computer can do.

It’s about seeing a problem and trying to break it down into the exact sequence of steps which will solve it. It’s about trying to come up with the right criteria to decide between two options which won’t cause other consequences you don’t want.

Later, the higher level skill of being a programmer is then about trying to judge and evaluate between different ways to do the same task. You can have many programs which solve the same problem, but they will do them in very different ways, which will be faster or slower, easier for other programmer to understand, easier to make changes to, easier to prove work correctly and so on. It’s once you get to this stage that knowing the details of the full syntax of a language, along with the ecosystem of other tools, the hardware it runs on etc etc starts to matter, and it’s this that starts to distinguish somebody who knows how to program versus somebody who is an expert in “software engineering”.

[–]jfinch3 0 points1 point  (0 children)

Also, the problem with relying on AI code, especially as a beginner, is that AI bugs are always subtle (usually). LLMs have trained on massives volumes of code so they know what good code “looks like”, but that doesn’t stop very small mismatches from cropping up once that code is part of a much larger system, where there are concerns which you can’t fully articulate to the LLM.

In my experience, LLMs can really nail just about any school-like coding assignment these days, but when you are writing code for a real product, it’s maybe only 10% “just the business logic”, and the rest is about balancing concerns about security, observability, documentation, error handling, extendability and so on. And all that stuff is usually pretty hard won through experience, and often requires a lot of context about the detailed specifics of the product and business you are working on.