The Beauty of Programming (2001)
brynmawr.edu
brynmawr.edu
"""
Why is programming fun? What delights may its practitioner expect as his reward?
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by the exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures....
Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.
"""
This is one important reason why many programmers aren’t very fond of AI coding. The relationship between prompt and LLM output is not very tractable.
People get over this and even grow to appreciate it from the perspective of the production code, but from the unit testing side it’s been an unrelenting nightmare from the time I started using the language professionally ~10 years ago until we got Copilot.
It’s total slop. Perfect for the slop generating machine.
This is both a reason that programming is enjoyable, as well as one of the reasons it's so easy to end up with a giant mess that kinda sorta works well enough to get by.
it’s an awesome feeling
If you really want to reconnect with the pure art of programming, just start a hobby project. Burn that candle at both ends. Grind through the self doubt. Grind through the challenge. Just keep perusing that 1 idea. If you finish it, you created your own little universe. If no-one sees it, who cares? Art is a form of expression and so is programming.
Nobody can judge you for it. There’s no deadline to meet. So what if it’s never finished? It’s cathartic to go as deep into the rabbit hole as you want, a freedom that your day job probably not grants you, and thus all the more valuable.
At least I realized I loose interest in my side projects the moment they become a chore, and then I remember to tell Dependabot to go to hell again.
It is still a bit buggy, but nothing that a reset can't fix.
These days I was interested in messing around with something different and went through rabbit hole of running FreeBSD in a VM. In an objective sense, it never had any purpose, neither I have any specific goal with it. From an outsider perspective, it’s all just a waste of time.
But it’s these little things — getting obsessed about making some random thing work (or trying until I’m convinced it won’t) — that makes me do things I normally wouldn’t, and I end up learning unexpected things on the way. I’m now trying to map the holes in my terminal and UNIX tools knowledge just because of that, and it led me to read more details about UNIX history, GNU history, watch videos on these things, look for blogs etc. You never know where something like this will lead you to.
Unfortunately, any reasonably complex side project eventually becomes work. It's still useful to keep grinding, as it builds perspective on why things are built the way they are, even when you have "freedom" to to implement them any way you like. What you don't have is infinite time though so if you wanna actually be able to use the darn thing, you have to settle for an imperfect design which soon enough will start to show it's limitations but instead of rewriting, you keep duct taping if because something that just works today is infinitely more business valuable than perfect tomorrow. Particularly when you realized from experience that tomorrow still won't be perfect, just late.
For clarification, I'm talking about building an automated trading system. And to get an idea of the complexity involved, just take a look at the "order" class in Interactive Brokers API. If you thought (side, price, quantity) is what defines an order, you're being naive: https://interactivebrokers.github.io/tws-api/classIBApi_1_1O...
Also even when you start with a mindset "I don't need all of this, my stuff will be simple", as I said, over enough time, use cases pile up and your original "simple" design either has to give way or become "useless".
See, that’s exactly what I was arguing against. Side projects are allowed to be for fun, they don’t need to have business value at all! Not everything you do needs to be a hustle. Doing something for the sake of doing, not achieving, is a great way of honing your skills while relieving stress. Human minds are not built for KPIs, but experiencing the progress of making something to your own design.
What you are working on seems genuinely useful, and if that gives you joy, all props to you. I however advocate for programmers that find joy in programming to work on a project far removed from any economic value, and just focus on the act of creating.
```
We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely.
All art is quite useless.
```
All my programming happens in the context of art (computer music and media art). I do all the things you describe while (indirectly) earning money with it. If you build something that you deeply enjoy, money won't take that joy away. I guess it's just hard to find this kind of satisfaction in typical corporate jobs where you're just a replacable wheel in the machine and your code will be replaced in a few years anyway.
I feel like this is not a realistic view to sustain in most modern tech environments, unless you love inefficiently producing ineffective solutions that just so happens to be profitable, or you job hop every 1 - 2 years.
Hot take: what if the rise in enshittification and crap tech is because good tech can only be produced with the hindsight of a stable tech career from a stable tech employer?
I don't think it's the employee's responsibility to stay in one company if the stability and in-house career path options are questionable, as usually is the case.
First company with 23, sold with 33.
Second + third company founded with 36, sold at 46.
I was the software engineer in the founders team, built alot by myself, even in the last years with a tech department of 30 people.
After doing nothing for 1.5 years, I am back with a new startup, being the only developer. Because I love it, and I am good at it!
It's my passion...
I've never been a founding engineer, but typically a direct report to founding engineers.
The people I worked with in your position were either like you (e.g. enjoyed programming but clearly got a big rush from the business and money side too) or they were genuinely just pure passionate programmers and miserable, as their role takes them away from that.
The fun gets sucked right out of it when you have people breathing down your neck waiting for your output, are very particular about what they expect from it in a way that doesn't align with your creative values, etc.
Not all of us have a Lord Saatchi willing to bankroll whatever our brains fart out and call the result brilliant (likely to pump up its value to buyers). Matter of fact, that may just be what ZIRP-era VC can be conceptualized as: business model "Uber for Lord Saatchi-style patronage in tech".
Then there's the free choice of hardware and stack, you never have to bend for some culture, styleguide or vendor lock-in. Blobs? coreboot makes your hardware feel like a living thing.
Since then i stopped to think of programming as work and dreading it. It's the complete platonic realm of ideas dancing in very real electrons.
Thanks for the article, it's a great reminder about how lucky one can consider himself and nice to see likewise minds.
Forge on!
Computers >> interactions with non tech humans (unless they are dead and wrote great books or music)
Great i can admit here a day without having to interact with non-coders is a gift for me lol
What did they look like? Tesseracts, polytopes? Stellahedron?
Were there monadic isomorphs, residual projecives? Both?
Did continuations self-order? Into simplexes?
I kept dreaming of an endless world of prime beings, I thought I'd never see.
And then,... one day,... I got in...
It was more fun then.
Someone would feed me, put me to sleep and change my nappies and I didn't have to lift a finger
Like someone else pointed out, you don't need kubernetes and microservices at home.
Something I learned late in the game as a programmer is how beautiful it is when multiple people somehow sync up and get into a flow state together. It is like a choir, where everyone is somehow elevated and together they achieve a lovely unity. Or a sports team where all of the players are locked in, seemingly reading each others' minds, and getting to some amazing transcendent place together. The book "The Boys in the Boat" describes this phenomenon beautifully. When all nine members of the team achieve this sort of locked-in unity, the boat just flies across the water.
In software, there are times when ideas seem to pass with electricity from person to person. People immediately build upon the thoughts of others. Ideas seemingly come from nowhere, a synthesis of the conceptual pieces held by each of the team members. You realize that some wonderful new way of doing things has emerged from the dialog, and no one person could have possibly gotten there on their own.
There is a wonderful old-fashioned phrase that describes this: "The whole is greater than the sum of the parts."
- Relationships with people - Creativity
You have to collaborate with people to fully understand the problem you are solving, and you can solve the problem in a creative way.
Not complaining. I'm just wondering if there is some context I'm missing.
Er, no, that's not at all what happened. Mandelbrot was trying to model real-world observations like the length of irregular coastlines varying based on the scale of the measuring unit, and the growth and decline of pond scum populations.
Also
> As any mathematician knows, you literally can have a set of mathematical equations in which three plus three equals two.
is quite wrong unless you're simply redefining the strings "three", "plus", "equals" and/or "two" to mean quite different things.
> Remember the person in school who always got the right answer? That person did it much more quickly that everybody else, and did it because he or she didn’t try to. That person didn’t learn how the problem was supposed to be done but, instead, just thought about the problem the right way.
That is quite confused and conflates several different things.
> The story goes that the great German mathematician Carl Friedrich Gauss was in school and his teacher was bored, so to keep the students preoccupied he instructed them to add up all the numbers between 1 and 100. The teacher expected the young people to take all day doing that. But the budding mathematician came back five minutes later with the correct answer: 5,050.
If this actually happened, I doubt that it took him as long as five minutes. And how does that square with "did it because he or she didn’t try to" ... surely Gauss tried to find a simpler way to calculate the sum. Also, Gauss had vastly more impressive achievements than this, although I suppose it depends on how young he was at the time.
> A great mathematician doesn’t solve a problem the long and boring way because he sees what the real pattern is behind the question, and applies that pattern to find the answer in a much better way.
Mediocre mathematicians do the same--I'm not even that, but I was on my high school math team and was routinely tasked with finding shortcuts to the answer. And great mathematicians spend their time creating (theorems, novel approaches, whole new fields of mathematics), not solving math problems (or calculating sums, which can barely be called math).
But yes, programming is great fun and much of that comes from the ability to make things happen in the real world--that's why I switched from my plan to be a math professor to becoming a programmer when I discovered programming while in high school many decades ago. And now I'm retired and still program both for the joy of it and the pragmatic results.
Which are the different rules he talks about. Obviously he does not say that all rules have to apply t at the same time. What a silly thing to interpret into his words.
>That is quite confused and conflates several different things.
It isn't though? It is definitely an experience I had during my mathematics degree.
>If this actually happened, I doubt that it took him as long as five minutes. And how does that square with "did it because he or she didn’t try to" ... surely Gauss tried to find a simpler way to calculate the sum. Also, Gauss had vastly more impressive achievements than this, although I suppose it depends on how young he was at the time.
The point he is making is actually pretty clear. Namely, that there is a distinction between a good solution and a great solution. A good solution takes the hard way and does all the right things. A great solution completely understands the problem and gives a solution so clear that after that you do not even see the problem.
>Mediocre mathematicians do the same--I'm not even that, but I was on my high school math team and was routin
If you ever have done mathematics at a university level you will have encountered exactly what Torvalds describes. In your homework you make all the right arguments, and through many steps you work through a difficult proof. In the end it is correct.
When another student presents their argument or when you later go through some textbook, there is a deceptively simple transformation and suddenly the argument becomes a trivial case of a previous theorem. Suddenly the problem has disappeared all together.
What makes a great mathematician is no doubt that ability. In fact if you ask a mathematician what makes a great proof it will be exactly this, taking something which looks incredibly complicated and suddenly transforming it into something incredibly obvious.
You say "who cares about that?" OK, 3+3=2 in a data field represented by only 2 bits. At least some of us here have actually run into such things.
[Edit to add: And if you don't care about it in 2 bits, you at least need to know about that it can happen in 32 bits.]