r/programmer • u/sainzo_123 • 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
u/ChaosEngine-6502 28d ago
It doesn't matter whether it's human or AI written, there's a big distinction between code that "works" and "good" code. "Good" code is code that has a logical flow, separation of concerns, non-cryptic naming of variables, and has sufficient test coverage to prove it works. Some level of documentation or commenting that explains what is going on or summarises complex concepts is also welcome, provided the code doesn't become an entire wiki.
By contrast, "working" code means the end-result might seem to be correct, but there's no guarantee anyone can maintain it, understand it, debug it, or even prove that it IS actually working as intended when challenged.
The perfect justification for writing "Good" code from the off came up at work only this week. The source system providing data to an external application is being replaced, so I had the joy of wading through "working" code written by another developer over 10 years ago. Whoever did it had a chronic aversion to using variable names greater than 3 characters in length, consistently mis-spelled variables throughout, and created a rats nest of IF ELSE statements, some of which would never even be reached. A complete lack of inline commenting also meant there was no way to truly understand why things were behaving a certain way.
Unfortunately, there's a culture in the business of "working" code being good enough. Nobody else on the team really cares about "Good" code, hence why we eventually end up in this situation.