The Code Compiled on the First Try
“she was beautiful, like code that compiles on the first try
but also you just knew that there was something deeply wrong with her, like code that compiles on the first try”
I remember learning to code, and being rather satisfied that my code compiled. Then I’d run the code, get a runtime crash and work to fix it. I mean, no problem (guys)!
These days I’ll get an AI agent to write some code and run it. It see the runtime crash, says it needs to “think about the problem in a different way” and it runs it again. The code crashes again…and on we go.
It sometimes feels like an LLM is the ghost in the machine, taking control of our lives. Making things work, making things broken at its own whim and behest.
It’s not beauty that I’m talking about. It’s the kind of luck and fortune that makes you pause and ask.
“Wait, why did this compile?”
When Everything Works Too Well
Something must be wrong. Something must be broken somewhere. Perhaps the tests are doing the “false positive” thing (again) because, after all, nobody writes tests correctly. It might be that the tests are simply pointing to the wrong file? Worst of all it might be that your mind is fried from a three-day debugging session and your clean build is actually a ticking time bomb waiting to fry production without a word.
Nothing good ever comes with zero cost, and that is something we would all do well to remember.
Because when something feels “too smooth”, and when something is going just too well it usually is. A PR approved in 5 minutes means that it’s not been read and might just have its own logic bomb hidden inside. A new hire saying that they are a 10x engineer while looking up on ChatGPT how to perform a git rebase. Or the CI pipeline going green for your PR when you didn’t update the tests.
It’s the mark of an experienced developer to know that the cleanest looking output can hide the messiest input. That means tech debt, unvalidated assumptions or that API call that points to the wrong endpoint are all silently waiting for the uninitiated.
What We Choose to Ignore Says So Much About Us
People gonna people. That means appreciating the surface level beauty of straight teeth, clean syntax and camelCase. Yet we all forget it’s what lurks under the surface which matters more. Those rockstar devs are notorious for throwing their colleagues under the bus just after shipping broken code.
Yet we’ve all been that dev, just a little bit. Beautiful from afar, but the implementation details tell a completely different story.
When code compiles the first time it might just be good luck. You’ve managed to fluke a good result, and well done you. But maybe it’s a trap. It’s a warning and something you need to take care of with just a little bit of attention. Or you might spend your time fixing those broken feature flags, because that would be a good idea too (wouldn’t it?), and what do you mean you can’t be bothered?
The Real Red Flag
Miracles don’t really happen. Sorry to break it to you, kid. A miracle would be something that compiles on first try, works and delivers exactly what you want is cake (a lie).
That’s the reason we have tests. That’s the reason we have code review (where a developer actually reads the code). Someone should be awake to your commit message that says “fix stuff lol”. Because our overall attention to detail matters, whole teams should be awake to what actually needs our attention and what we actually need to do.
Because it’s not just code that can be too good to be true, it’s people too. Which brings us full circle. When you see the perfect person you know there is something wrong. When you look closely at code you know there same.
It’s just that you don’t want to look too closely, do you?
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper and regularly publishes articles through Medium.com
Trusting code that compiles on the first attempt? The Secret Developer trusts nothing and nobody, which is why they write blog posts alone.