Merleau-Ponty argued in "The Visible and the Invisible" that true meaning emerges not from the object itself but from its interaction with the world. Similarly, code finds its true significance not in its internal structure but in how it manifests as product and interacts with users. The code's invisible essence is meaningless without this manifestation.
Of course, this is not to say good code doesn't exist, here is an example of it.
x = a+c
You might be surprised at the choice. It inherently tells the computer what it wants. The interpreter then takes every token of that code on a beautiful journey to the silicone. It tells you, the reader what you need to know - when you break it down, how you understand code, and how a computer understand code are fundamentally similar.
An uglier way to use this code would be to wrap this in a function. Instead, this expression is enough - it tells you the expected input and where to store it. For this, you must think like a mathematician - a mathematician wouldn't define f(x) but just write out the values she wants to add.
"Against Method" argues that scientific progress often comes from breaking methodological rules rather than following them. In software, slavish devotion to "beautiful code" principles can become a methodological prison that prevents innovative solutions. The product's needs should drive methodology, not vice versa.
The "one function should do one thing" adage is odd, and really bad. A function should serve its own purpose, and that is it - it doesn't have to do one thing, or even a few specific things. If it is 30 lines of gibberish, you can balloon it up to 50 by adding pointless, costly and as Spolsky says, leaky abstractions and every try-catch failure. "Magic numbers are bad" - this entire system of programming is bad, stop moving things to constants.py.
I would also say: avoid languages made for idiots. Pythonic way of declaring member methods (def x(self)) is ridiculously ugly - it makes you think from the class' perspective - you're not a class. OOP is a wonderful paradigm of programming if you want to get an A on some redundant Java class, but in real life, it's a sure-fire way of adding costly abstractions where you don't need to (Dog inherits from Animal, why not just start at Atom, or Electron - just in case you need a Car class tomorrow). Python retrofits typing system into its interpreter - and it makes developers feel nice about a language that is so broken, it makes the act of using its top ORM feel like a chore. "My scripting langauge needs an environment manager" said no developer ever.
Most people remember upto 3-4 layers of abstractions. 5-7 if they're experts. This is called Miller's law, or Cognitive Chunking (and I'm sorry to borrow from a subjective and unserious field such as psychology).
This is not to say Python by itself, is bad. It is one of my favourite languages, but 1) Backends in Python are ridiculous, 2) Stop treating it like a Statically typed languages. Go was built for idiots, it knows that, and it works really well. It is the perfect language for backends. Python was built as a scripting tool for researchers, it knows that, others don't.
To change gears, consider, React.
if (isLoading) return <LoadingSpinner />; if (error) return <ErrorMessage error={error} />; return <UserData data={userData} />;
Isn't this beautiful? There are places where they will remove your kneecaps for this. Instead they want nested ternaries.
return ( isLoading ? <LoadingSpinner /> : error ? <ErrorMessage error={error} /> : <UserData data={userData} /> );
Note: Abstractions are fine, just don't be ridiculous.
I apologize again for borrowing from psychotherapy, but Eugene Gendlin, developed this concept of the "felt sense"—an embodied understanding that precedes articulation. To borrow this in userland - consider this: Users experience software through this felt sense of interaction, not through appreciation of its underlying architecture. This is known - but we are willing to adhere to "best practice" and not reinvent wheels. We're okay with ridiculous joins (which even after performance improvements are slow) instead of just building an in-house data or cache store that your engineers will enjoy working on. We must pay for every service for short term convenience instead of trusting engineers internally. This is C-suite thinking - and as I will argue in another post, executives are the diagnosis of a healthy society, but prognosis of a fallen world. Of course, don't reinvent cryptography, don't waste time building foundational models when you live in a developing world with scarce energy and scarcer literature (looking at you, Mahindra) - but time to time, do what Groq did. Figure things out, especially if a large engineering lift results in a large payoff.
In software, the "Other" is not fellow developers admiring your code, but users depending on your product. This ethical perspective demands prioritizing their experience over professional self-satisfaction. In healthcare backoffice, we learnt this the hard way - that this is true. Often back breaking, grunt work, has a ridiculously high payoff. If you've not read "A Short History of Decay", I suggest it, though you, like me, will probably DNF, but it warns against the human tendency to create and worship abstract ideals detached from reality. "Beautiful code" often becomes such an abstraction—a platonic ideal that developers pursue while neglecting the messy, concrete reality of user needs. If you're being highly agentic, think about what codes can you break (no pun intended).
Another one of these ideas is comments. One of my bosses put it well - stop fucking commenting on every line of the code. Sometimes, somethings don't need comments. They don't need docs. They're self-sufficient. Git blames are good enough - but by itself, a simple if-statement for an already documented case doesn't need another comment.
All this to say, I am probably not a good programmer. Your mileage may vary. But do not be obsessed with code quality and beauty, just write the fucking code, make sure it works in all cases. There is no beautiful code, only beautiful products.