Elegance

December 29, 2025 | 8:47 AM ET

I came to the realization last night while trying to sleep that many of my thought-processes, actions, and routines are dictated by my view on elegance in computer programming, which was hurting my ability to form productive habits in my day-to-day life. This essay discusses my view on elegance, how it's nice in the abstract and small-scale, how it's impossible in production environments, and how it relates to the real-world.

When software engineers refer to "elegance", they mean some nebulous quality of their program that makes it nice. Everybody has a different interpretation of this, and it surely changes based on the program being implemented. A nice book discussing elegance in computer programs---which I also referenced in my own Bachelor's thesis, which is also a broad exploration of this same topic---is Beautiful Code, edited by Andy Oram and Greg Wilson. This book is a compilation of a few dozen software engineers' stories about code they wrote or witnessed that they perceived as being "elegant." An example of two programs I remember are a regex parser (chapter 1) and a stencil solver (chapter 8). The first was a very succinct 50-line pattern-matcher in C that implemented 95% of all regex queries (with the remaining 5% using fancy stuff like negative lookaheads, which most people don't use). The brevity of the code hints that it is well-designed and reuses much of itself for different tasks. Alternatively, the second was a nice program that eliminated much of the loop overhead associated with computing arbitrary stencils on images by compiling a snippet of C# code on-the-fly. Code-generation has a tendency to get complex quickly, so their encoded representation of stencils and their subsequent translation of them to C# in an organized way was nice to think about.

Both of these programs, and undoubtedly all of the programs in the rest of the book, demonstrate a quality that I view as integral in "elegance": universality. This is why short programs is often preferable to long programs that do the same task, because short programs tend to have a single line of code implicitly do more than one thing while semantically representing only a single idea. For example, the regex parser has different kinds of matches it can perform, with simple expressions matching fixed letters (e.g., "a", "aaaab", ...) and other expressions matching nondeterministic groups of characters (e.g., "a+b", "((a+b)+a)+", ...). A simple implementation would create code that matches these two types of patterns separately, while an elegant solution would recognize the underlying uniformity shared by both types of matches (that they can be represented as a finite automata, regardless of their form), sharing code used by each. The elegance doesn't stem from the code being maximally concise, since that wouldn't be good due to readability, but from the programmer uncovering a kind of singular beautiful cohesive thread stitched through the program that unites and completes this task without splitting.

Thus, if universality is the target of elegant code, exceptions are the enemy of it. If you want to design a program that matches any character, then matching the null character `\0` would be a problem since that's treated as a special sentinel in C strings. Key sections of that 50-line parser must now be redesigned to account for a string length independent of the null character. The program might look even more different if the patterns could match UTF-8 characters, which C strings are naturally unable to account for due to characters being potentially more than one byte each. However, it's still possible to make the program elegant (the thing that made it elegant before was the representation of a simple automata in a small space, not necessarily that it was represented in a small space in general), it just becomes less intrinsically elegant the more exceptions you account for.

This becomes doubly so when trying to create code that's actually safe. Safety in computer programming is impossible to completely account for (e.g., a solar ray could flip a bit and trick the program into thinking it's in a safe state when it should have caught an exception), though it can be severely mitigated by littering the code with guards and checks. When designing a program to launch experiments for my research project in November, I noticed that creating a set of simple scripts would likely take 100 lines of Bash code in total, while my highly-engineered parallelized very-safe Python solution took about 1500 lines. The benefit is that those Bash scripts would be completely unusable in the long-term and would give extremely obscure errors if the computing environment didn't match my strict assumptions, while I'm confident the Python scripts could be sent to any artifact-evaluator months in advance and still have the results replicate. Unfortunately, the huge volume of if-statements and assertions checking for every possible missing file, failed system command, and malformed experiment state adds up in code overhead and developer time, to such an extent that my tested, highly-documented, and for-all-intents-and-purposes "good" program is still exhausting to look at.

In either case, I certainly view my 1500-line program as better than any concise set of Bash scripts. It's true that I over-engineered it, though this is acceptable for the clear benefit in reproducibility and the ability to send the code to anybody. Though... another unfortunate consequence of the program is that despite all my efforts, it still remains imperfect. I make several key assumptions in the program, like "there will exist enough memory to perform this experiment" (which will not be true, since this generates nearly 300 GBs of traces) and "an experiment which reserves a GPU will continue to exclusively have that GPU until it's complete" (which was a difficulty even in my own server with 8 other PhD students submitting to similar places at the same time). Furthermore, I could correct these surface-level issues, though there surely exists a near-infinite number of other problems that are intractable to account for. In a way, this dissolves my perfect elegance with my program: I sacrificed brevity and elegance not for universality, but for "almost universality", which is not universality at all.

I realized I have this same mindset when approaching things that are not software engineering, too, and it's restricting my ability to be productive at times. The example I return to is with working out: it's something I should do regularly and is good for me, so I should do it three times a week. However, there are three critical flaws with having an attitude as lax as "work out three times a week": (1) the highest benefit is obtained by spacing these days out, to give my body proper time to recover; (2) delaying days could lead to one week having two workouts while the next week having four, so its best not to delay days at all to keep things strictly uniform on the same scheduled days; and (3) my PhD work may require I travel to conferences across the world, so working out will be impossible at those times, leading to a missing day in my schedule.

For a software engineer trying to create an elegant program, it's natural for these exceptions to dictate the design of the program. We want to create a program that's universal in its formulation, such that everything clicks together in such a snug and aligned fashion that no glue or tape is required. For my workout routine, that kind of solution would require a huge level of motivation and willpower to achieve, with my a rigid portion of my schedule devoted to adhering to it perfectly. This leads to my workout routine dissolving before it even has a chance to begin.

However, as with programs, utmost elegance is not possible in production environments. We can have elegance in the abstract sense, with systems being elegant as how regex parsers can represent their patterns in automata, though the low-level implementation cannot often represent this with any level of complete correctness or machine-independence. Thus, a better solution to my workout problem is to treat these exceptions exactly as they are: something to catch as they come. A proper program does not revolve their design around the possibility that `malloc` may yield a null pointer, or around the user removing a file as it's being written; the program should make its own assumptions about its correctness, catching the rest of the reasonable cases (and adding assertions for unreasonable cases only so far as they accelerate development). Similarly, my workout routine should not even consider the once-a-year situation in which I am traveling, and it certainly shouldn't view it as bad if I work out four times in a given week instead of three.

This thought-process can extend to many different areas of my life. One such area is with social media: I tend to spend a lot of time online, and it certainly doesn't make me feel rested or happy after a certain amount of hours devoted to it in a given day. However, I realized that once I open the app for the first time, I tend to keep it open for extended periods. It's much easier for me to not open the app at all rather than open it for only a few minutes at a time. Therefore, a simple schedule would be to never open social media at all, which would completely curb my online addiction.

Though this relates back to my problem with exceptions: when my brain sees "never," it thinks of all the cases where viewing social media would be acceptable or positive. Connecting with my friends online and interacting with them is something that has improved my life. Also, engaging with my interests of anime and manga is something I've tried and failed to do outside of the internet, so social media is something that allows me to interact with people and media related to this. I've attempted to solve this by strictly outlining the cases where social-media usage is allowed (for example, at night, on weekends, and/or when no other work is due) and consciously preventing cases where I can see myself using it outside of these exceptions. This is still a work-in-progress, but I'm optimistic this perspective can improve my ability to form stable habits.

Elegance is a nice goal to obtain, but it's not possible in the real world in the same way formal logic isn't applicable to real situations: the world we live in has too many exceptions that the logic must consider, so plainly dismissing it or accepting a less-ideal solution is acceptable to make a functional system. I hope this can be a positive thing, and it opens a path for forming realistic, successful, scalable, machine-independent, semi-universal programs, schedules, habits, and people alike.