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.
I have to work in a very explicit, verbose language where we are expected to write mostly mock-driven unit tests to a 95% coverage standard. Although I would prefer to use a nicer language and adopt a more nuanced testing strategy, I find that for the situation I'm actually in, AI increases tractability by a lot.
Java has exceptions and can mock at runtime using reflection. Go is much worse. If you have glue code that calls 5 methods in sequence, you need to set up build rules to generate 5 mocks for the corresponding interfaces. And then if you’re like me, re-sync the editor so it picks up the generated symbols. Then you need to write 1 + 2 + 3 + 4 + 5 mock expectations for the 5 test cases to reach each error return branch. Oh and the mock expectation arguments are immune to automated refactoring because they’re all interface{}. So if you want to change the arguments of a method that’s implicated in a lot of test cases, lol good luck.
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.
also, AI coding is not coding to begin with: the AI does the coding... you might get to chime in, but this already means you've squandered a part of the coding to the AI, and not just the boilerplate part
> 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.
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.
personally is the automation side of things, create something that saves me time and reduces errors, or invent some rules like unrealistic physics) and watch it all play out, even better when adding interaction and feedback, all the while breaking my head against the wall trying to debug or account for all edge cases,
This is why you should program for fun instead of just for money. Sure its fun creating some interface for an API. Sure its interesting to figure out a problem some customer is having. Sure, it can be rewarding to create a new system as part of your companies product. But you know what is really fun? Creating something from scratch. Sculpting it. Refactoring it. Trying things. Cutting things. Learning things. Exploring new ideas. All of the stuff that typically doesn't fit well when money is involved.
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.
A word of advice that you might or might not need to learn on your own: Don’t let all the habits from work creep in—dependencies, tooling, code style, neat documentation, multi-platform support, proper commit messages—and most importantly, any notion of "MVP" or "feature creep". Try to make an effort to get side tracked while you’re side tracked, do things that you couldn’t justify doing at work, the stuff no user would notice, the polishing that you’d always postpone, or the massively overengineered spec-compliant OAuth server in your personal book library.
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.
This is so true. It’s good to be reminded of it. Doing these kind of things is what keeps me interested in the field.
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.
>> At least I realized I loose interest in my side projects the moment they become a chore
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".
I think it's an incredibly spoiled perspective that anything that becomes a chore is no longer fun or worth doing. Practicing piano is a chore. Repeating the same piece, the same finger movements for an hour or two isn't necessarily fun. But it is satisfying at the end of the day and it is fulfilling. Fun isn't necessarily the goal. I can spend hours banging my head against the wall while trying to build a piece of software. It can be tedious, frustrating, and tiring. It's rarely "fun". But in the end, it's satisfying and it's fulfilling and tomorrow I'll do it again because I want to.
> you keep duct taping if because something that just works today is infinitely more business valuable than perfect tomorrow.
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.
> But you know what is really fun? Creating something from scratch. Sculpting it. Refactoring it. Trying things. Cutting things. Learning things. Exploring new ideas. All of the stuff that typically doesn't fit well when money is involved.
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.
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.
My programming brain has two modes. One is playful mode, and the other is drudge workaday mode. 9-to-5 Monday through Friday is workaday mode. Other times are playful mode. As it turns out, I am a far better programmer in one of those two modes. It won't be hard to guess which one. In drudge mode, I may spend three hours some afternoon trying to force my way through a problem. No turning back, the clock is ticking! In play mode if I spend three hours goofing around with the exact same problem and it's kinda not happening, well, screw it. That was sorta fun, but let's goof around with it some more and try something else. BANG! Sweet clean obvious beautiful solution straight from Erdos' BOOK. The powerful sense of joy in the latter mode sustains my love for programming, but I wish I could convince my lizard brain that it would be OK, indeed far better, to stay in play mode and not get sucked into the dark doldrums of drudge mode during "job" time.
I’m convinced that going for a walk, or staring out of a window, or browsing Reddit, or even taking a nap to let your brain work is an essential part of programming work and that should be understood by any employer. And employee.
May I ask approximately how old you are and what field you're working in? (Or, being passionate in?)
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.
There's a whole categories of skills, abilities and problems that are never confronted if a person changes job every <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?
That's a different topic though. This was about passion in coding for living.
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.
If your job is your passion, and your downstream customers give you freedom to treat it as such, it can be fun.
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".
I liked my programming at work, but i love the programming i can do now with 0 pressure and constraints. I can see every line and working function mirrored in my real environment and not being extracted by some outside owner.
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.
The Graph. Infinite, computational, abstract. I tried to picture clusters of information as they moved through the transforms. Time shifting through memory cells.
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.
There is this wonderful concept of "flow state", which I'm sure most of us are familiar with. It was originated by Mihaly Csikszentmihalyi. Many of us in this thread (and Linus's essay quoted in OP) are referring in various ways of getting into the flow state while programming.
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."
Then there is the joy of making the program source code as easy as possible to comprehend. This motivation seems to be rather unusual among programmers unfortunately.
> Mandelbrot just made up these arbitrary rules about this world that doesn’t exist, and that has no relevance to reality, but it turned out they created fascinating patterns.
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.
>is quite wrong unless you're simply redefining the strings "three", "plus", "equals" and/or "two" to mean quite different things.
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.
I like how Frederick Brooks put it:
"""
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.
"""
> Finally, there is the delight of working in such a tractable medium.
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.
I have to work in a very explicit, verbose language where we are expected to write mostly mock-driven unit tests to a 95% coverage standard. Although I would prefer to use a nicer language and adopt a more nuanced testing strategy, I find that for the situation I'm actually in, AI increases tractability by a lot.
Are you an enterprise Java dev by any chance?
Java has exceptions and can mock at runtime using reflection. Go is much worse. If you have glue code that calls 5 methods in sequence, you need to set up build rules to generate 5 mocks for the corresponding interfaces. And then if you’re like me, re-sync the editor so it picks up the generated symbols. Then you need to write 1 + 2 + 3 + 4 + 5 mock expectations for the 5 test cases to reach each error return branch. Oh and the mock expectation arguments are immune to automated refactoring because they’re all interface{}. So if you want to change the arguments of a method that’s implicated in a lot of test cases, lol good luck.
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.
also, AI coding is not coding to begin with: the AI does the coding... you might get to chime in, but this already means you've squandered a part of the coding to the AI, and not just the boilerplate part
I find it completely devoid of joy, the frustration without the satisfaction and growth.
> 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.
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.
If it works, it works
That was delightful. Thanks for sharing.
personally is the automation side of things, create something that saves me time and reduces errors, or invent some rules like unrealistic physics) and watch it all play out, even better when adding interaction and feedback, all the while breaking my head against the wall trying to debug or account for all edge cases,
it’s an awesome feeling
Wonderful excerpt. What's the source?
It's a section titled 'The Joys of the Craft', from Chapter 1 of The Mythical Man-Month:
https://home.adelphi.edu/sbloch/class/adages/joy.html
This is why you should program for fun instead of just for money. Sure its fun creating some interface for an API. Sure its interesting to figure out a problem some customer is having. Sure, it can be rewarding to create a new system as part of your companies product. But you know what is really fun? Creating something from scratch. Sculpting it. Refactoring it. Trying things. Cutting things. Learning things. Exploring new ideas. All of the stuff that typically doesn't fit well when money is involved.
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.
A word of advice that you might or might not need to learn on your own: Don’t let all the habits from work creep in—dependencies, tooling, code style, neat documentation, multi-platform support, proper commit messages—and most importantly, any notion of "MVP" or "feature creep". Try to make an effort to get side tracked while you’re side tracked, do things that you couldn’t justify doing at work, the stuff no user would notice, the polishing that you’d always postpone, or the massively overengineered spec-compliant OAuth server in your personal book library.
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.
This is so true. It’s good to be reminded of it. Doing these kind of things is what keeps me interested in the field.
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.
This days for joy programming everything I do is inside Picotron and with LUA.
It is still a bit buggy, but nothing that a reset can't fix.
https://www.lexaloffle.com/picotron.php
I got their Pico-8, and it really brought back the fun of programming for me.
>> At least I realized I loose interest in my side projects the moment they become a chore
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".
I think it's an incredibly spoiled perspective that anything that becomes a chore is no longer fun or worth doing. Practicing piano is a chore. Repeating the same piece, the same finger movements for an hour or two isn't necessarily fun. But it is satisfying at the end of the day and it is fulfilling. Fun isn't necessarily the goal. I can spend hours banging my head against the wall while trying to build a piece of software. It can be tedious, frustrating, and tiring. It's rarely "fun". But in the end, it's satisfying and it's fulfilling and tomorrow I'll do it again because I want to.
> you keep duct taping if because something that just works today is infinitely more business valuable than perfect tomorrow.
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.
> But you know what is really fun? Creating something from scratch. Sculpting it. Refactoring it. Trying things. Cutting things. Learning things. Exploring new ideas. All of the stuff that typically doesn't fit well when money is involved.
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.
from mr. oscar-wilde
```
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.
```
My programming brain has two modes. One is playful mode, and the other is drudge workaday mode. 9-to-5 Monday through Friday is workaday mode. Other times are playful mode. As it turns out, I am a far better programmer in one of those two modes. It won't be hard to guess which one. In drudge mode, I may spend three hours some afternoon trying to force my way through a problem. No turning back, the clock is ticking! In play mode if I spend three hours goofing around with the exact same problem and it's kinda not happening, well, screw it. That was sorta fun, but let's goof around with it some more and try something else. BANG! Sweet clean obvious beautiful solution straight from Erdos' BOOK. The powerful sense of joy in the latter mode sustains my love for programming, but I wish I could convince my lizard brain that it would be OK, indeed far better, to stay in play mode and not get sucked into the dark doldrums of drudge mode during "job" time.
I’m convinced that going for a walk, or staring out of a window, or browsing Reddit, or even taking a nap to let your brain work is an essential part of programming work and that should be understood by any employer. And employee.
If you want to kill passion for anything make it your job
For me it's the opposite: if your job is your passion, it doesn't feel like a job anymore!
May I ask approximately how old you are and what field you're working in? (Or, being passionate in?)
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.
47 now
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...
One option is to become a freelancer, there you usually get a new project every 6-18 months in my experience.
There's a whole categories of skills, abilities and problems that are never confronted if a person changes job every <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?
That's a different topic though. This was about passion in coding for living.
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.
If your job is your passion, and your downstream customers give you freedom to treat it as such, it can be fun.
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".
I liked my programming at work, but i love the programming i can do now with 0 pressure and constraints. I can see every line and working function mirrored in my real environment and not being extracted by some outside owner.
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!
Programming is fun because in 99.99% of the time, the error is on my side, while the number is unclear when dealing with other humans.
Computers >> interactions with non tech humans (unless they are dead and wrote great books or music)
Why bit shift >> ???
Great i can admit here a day without having to interact with non-coders is a gift for me lol
Haha that’s greater greater
I miss getting lost in something, forcing yourself to stay up to achieve the vision
The Graph. Infinite, computational, abstract. I tried to picture clusters of information as they moved through the transforms. Time shifting through memory cells.
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...
This is a reference to a Tron quote, which I heard in this remix of the Daft Punk song "The Grid" from the Tron soundtrack.
https://www.youtube.com/watch?v=DdIdZwDqkmg
(2001)
It was more fun then.
Sure, but you can still program in C after hours and pretend like it's 1999 without any issues.
Like someone else pointed out, you don't need kubernetes and microservices at home.
You actually often don’t need it at work either, but everyone has been convinced that there’s one right way despite workloads being different.
Agreed
Someone would feed me, put me to sleep and change my nappies and I didn't have to lift a finger
I'm still coding like it's 2001!
There is this wonderful concept of "flow state", which I'm sure most of us are familiar with. It was originated by Mihaly Csikszentmihalyi. Many of us in this thread (and Linus's essay quoted in OP) are referring in various ways of getting into the flow state while programming.
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."
Nothing compares to the constant switching between feeling like the stupidest person on planet earth, to feeling like the smartest one.
Hold up…there’s a smart mode?
For me programming is fun because it involves:
- 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.
Then there is the joy of making the program source code as easy as possible to comprehend. This motivation seems to be rather unusual among programmers unfortunately.
Why did this get shared today, and why the excerpt posted on Bryn Mawr?
Not complaining. I'm just wondering if there is some context I'm missing.
Totally describes my experience, since 1965.
From 2001
> Mandelbrot just made up these arbitrary rules about this world that doesn’t exist, and that has no relevance to reality, but it turned out they created fascinating patterns.
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.
3+3=2 in a modulo 4 ring.
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.]
Damn that's smart, I read the comments wondering the same!
>is quite wrong unless you're simply redefining the strings "three", "plus", "equals" and/or "two" to mean quite different things.
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.
The "¾" in the text are actually emdashes. Clearly the text was AI generated, and then obfuscated to hide that.
The post was written in 2001.
I wouldn’t be surprised to hear the AI advocates promising time travel soon.