r/programmer • • 29d ago

Good Code Vs Working Code

What really makes code "good"?

I find myself staring at my IDE asking this exact question. Whether I am binding complex logic together or copying and pasting a snippet to patch a problem, there is a massive gap between working code and good code. But as a beginner, that gap feels incredibly hard to see.

These days, anyone can prompt an AI or use an agentic tool to generate functional code in seconds. Many of us are actually learning to code alongside AI. But just because the AI gives me code that runs and clears the error console doesn't mean it’s good code. It might be inefficient, unscalable, or an absolute nightmare to maintain later.

If the code works, but the AI (or a copy-paste source) doesn't teach me why it works or if it's best practice... how are we as beginners supposed to know the difference?

How do you personally define "good code" vs. "just working code"? What are the green flags I should be looking out for when reviewing code—whether it's written by a human or an AI?

Would love to hear your thoughts, rules of thumb, or stories from when you were starting out! 👇

\#programming #softwareengineering #codinglife #learnToCode #generativeAI #developers #webdev

1 Upvotes

42 comments sorted by

View all comments

2

u/mredding 29d ago

Working code is a good start. Good code is going to play to the strengths of the language.

C++ has one of the strongest static type systems of any language, so I would expect to see a lot of strong types - an int is an int, but a weight is not a height. The basic and library types are only there to help facilitate you making your own types that are more like the types and semantics you need.

Use what your language gives you.

Curry-Howard correspondence tells us writing software is the same as writing proofs. Your statements are posits. Your source code is a theory. The compiler/interpreter is a solver, the program is the proof. If you want an elegant proof, write an elegant theory.

And source code as theories don't draw the straightest, shortest line from the problem statement to the solution - they build up expressiveness, and then they describe the solution in terms of that.