To use another sports example, I watched "The Last Dance" recently. There's footage of Dennis Rodman working out and he says to the camera, "Its not just basketball we have to deal with on this team... Its the pressure of the bullshit. I'll play the game for free. You get paid for the bullshit after. Basketball is a simple game, but when you leave this confined zone. Its hard."[1]
That's why people get disenchanted with programming (and with a lot of other things)! We love to do the actual core activity. We love it so much we do it for free. You get paid for having to deal with the pressure to succeed. And you get paid for having to do all the other stuff that comes along with it.
Its the other stuff that grates on you until you hate it.
I see it as: it's the "bullshit" that creates the value for others.
Basketball, or programming for your own pleasure is just that: pleasure. of course you'd do it for free if it's something you enjoy.
But the fact that it has to generate value for others is what removes the fun. You will have to make changes to your priorities, take into account others' preferences, etc etc.
Luckily if done right generates enough money to compensate for that.
This is (in a roundabout way) also the main problem with all the "FOSS maintainers don't get paid enough" threads IMO. The dream is to get paid purely for writing software, without having to do marketing, sales, support or any of the other things that come with running a company. You just write code for the features that excite you and then money somehow appears. Sadly the non-fun bits are crucial to the getting paid bits.
Engh... I think the issue is that a lot of open source maintainers ARE doing that work but are doing it FOR FREE and it is burning them out, because they AREN'T doing the thing you are saying where they just write the parts that excite them: they are also triaging bugs and incorporating feedback and are having to constantly answer people demanding timelines... if they weren't doing all of that stuff we honestly wouldn't talk about the issue so much as we wouldn't be caught in a lurch when they stop providing us all that free value!
May be some open-source software becomes notable without any marketing or sales, but I constantly see a lot of very conscious effort by FOSS maintainers to popularise their work. They go to meetups, do talks, post on twitter and HN. And yet the most that majority of them can hope for is getting a boost to their resume and being hired as a distinguished staff/principal-level engineer somewhere because of their open-source clout.
Money is information. If maintainers eschew their own marketing, sales, and (paid) support then they lose access to this information. When someone else interprets the information provided through payment and non-payment their interpretation flavored by their own goals and shaped by their (mis)understanding of the product will introduce noise (i.e. bullshit) into the signal.
The goal for maintainers who dislike the business side of things should be to write code that makes those business activities as painless as possible for the maintainer themselves. In writing such code they will develop a greater understanding of the process and may even learn to appreciate it. A true win would be to generalize that code so that other maintainers can use it to make their lives easier while still being able to glean valuable information from it.
Money will never compensate fun. It's just what you do so you can eat at all. I have not met a single person who on their deathbed thought "I could have had more fun, but that's fine because I have money".
Not on their deathbed, but before that, having money can help you have more fun, if not while working, then at least in your free time. It doesn't have to be obscene amounts of money, but if you're constantly broke and can't afford anything, that's definitely not fun either...
> But the fact that it has to generate value for others is what removes the fun.
It could also be the one thing that makes your work meaningful.
I don't think the focus on value-for-others in itself is the fun-killer, but that there are diverging, in-congruent quotas to satisfy, that there are meetings that waste time, that design-by-committee makes the products dumb, that you lose autonomy, that there are more boring things to do than interesting things.
I think everyone needs and wants validation to varying degrees, and providing value to others is the means to achieve that (also.. money). Some people are less motivated by this than others, granted, but cannot exist in a bubble without going nuts. Even if programming were just for ourselves, some other labor is geared to others.
This is absolutely the implication. If you’re getting paid for everything else, then that is what is generating the most value.
The point is when someone says “how could you not love programming?” The answer is because “programming” is just incidental to what people are doing at the professional level. Because for professionals, programming comes along with the notion that if you do not succeed you will lose your job and potentially your livelihood and then its far too easy for programming and dread to get linked in your head. I think because programming is creative so it is in some way an expression of yourself its easy to get too attached and frustrating when there’s this other thing attached.
We get paid to do this thing called “software engineering” but programming is a big part of it and programming has elements of a creative discipline. The same way I cannot guarantee a song will be a top 40 hit even if it is sound in a music theory sense, I cannot guarantee a piece of code I write will be useful or valuable even if it is bug free.
I think this frustration is part of all fields where creativity is a component (musicians, filmmakers, athletes, journalists, researchers, mathematicians) but we sell what we do as a strict engineering discipline. But it’s not. If it were a strict engineering, why would we create KPIs or go over click rates or usage statistics with engineers?
People who talk about wanting to do “pure programming” somehow without dealing with customers or anything outside their own skull is, to me, like people who consider themselves artists without producing art which people can experience. What is art for, if not to be viewed and experienced? What is a program for, if not to be used for some practical purpose? For a person to be considered a programmer, their role must be to solve problems for people who cannot or would rather not solve the problem for themselves. People who instead want to sit and stare out the window and only occasionally write things down, they are like mathematicians in academia. These people are of course useful, but I would not call them “programmers”; perhaps “computer scientists”. Other people, who instead want to produce “beautiful” snippets of code, are effectively artists, the art of which other programmers can certainly enjoy. But I would not call such people “programmers” either. (Perhaps “computer scientists with tenure”.) Programming is to solve problems for other people (possibly including oneself).
I.e. if you don’t like to solve problems for other people, then programming is not for you, and you should consider becoming a computer scientist instead.
The gatekeeping is strong in this one. Why does it matter how you label people? (emphasis added because that's not how people generally define programmers) Just let people do what they want.
My “labeling” is a form of expression to describe my point. You can disagree, but please be explicit instead of just going “well, that’s just what you think”. This is a discussion forum; I expect people to have differing opinions, and I want to debate them. You just seem to want to instead shut down any debate.
And yes, I do want to “gatekeep” any profoundly unhelpful people out of programming. Programming should be about helping people do things they otherwise don’t know how or could not do for themselves. Navel-gazers and gnostics (while they have their proper place and use) are generally not suited for, and reflect poorly on, the vocation of programming.
I don't know. I've written programs used by millions in an enterprise-grade code base and the amount of paperwork, poor management, meetings and mandatory HR trainings made the process not much fun at all, even if compensation was pretty good. OTOH I really enjoyed the programs used just by me, written in my spare time exactly the way I want.
I can relate to both: if you can be proud of your work ("I helped build this, and hundreds of people are using it"), that's a good feeling. If however the process is bureaucratic and you feel like a small cog in the machine without any influence on how the project will turn out, then I can understand that it's not a satisfying experience. Depending on the project, you can also have both - on some days you will have the former feeling, on some days the latter.
>I see it as: it's the "bullshit" that creates the value for others.
There's some bullshit (i.e. non-coding activity that's tedious but still needed) that creates the value for others involved.
But there is also tons of bullshit that destroys value for others, society, and even for the company itself. Without the latter kind of BS we'd be far better as society.
Definitely. I got to experience programming before and after doing it professionally. My passion for it left, then returned as quickly as it left. I always loved programming, but doing it professionally just wasn't the same.
One of my colleagues often asks how I have the energy to code after work. The reason is simple, one is coding things that give me a comfortable life, the other is coding things for pleasure. They're also very specifically not the same subject area at all because that would be awful.
"Play" is doing something you want to do. "Work" is doing something someone else wants you to do or needs to be done. The former gives you complete agency, the latter is a reduction of your agency. If that something is valuable enough to someone they will pay for someone else to do that thing they can't or don't want to do (the pay is necessarily related to the value they have assigned as well as the retention of their agency in the matter). Of course they have to find that someone else that is willing to do that something for the pay offered, which means that someone else has to weigh whether the loss of agency is worth the payment offered to them.
It is not so much that "we love to do the actual core activity" since there are few programmers that would enjoy being constrained to constantly re-implementing basic CRUD functionality for months or years. We instead love the core activity driven by our own agency, doing what we want simply because the reward is satisfying that want.
Absolutely. I would have worked for SpaceX if they let me sleep in a hanger, they wouldn't have to pay me.
I would work for free for a company making widgets for which people paid cash money if they let me work on interesting problems, interfacing with my customers, so as to see the fruits of my labor pay off.
Happiness isn't always derived from that which our society says it should be.
I think you're missing a /s tag there, as 20 years ago was the end of the first dotcom boom, which was surprisingly similar to today in terms of vague business plans getting huge amounts of money thrown at them, and a lot of people getting into software for the money.
That's why Open Source (the "Individual-OSS", not "corporate/PR-OSS" that is also very popular today) is still great and pervasive. People writing code to solve their own problems, publishing the code for everyone to use if they want to, with no expectations of anything else than "Here is the code, do what you want with it".
Also, most "great" software available in 2002 can still be accessed today.
You wouldn't want to run it though.
Which OS to start with?
- Windows? Unpatched Windows XP gets compromised within minutes on the internet. Microsoft spent years trying to fix all sorts of trivial security holes.
- Linux? Have fun with Mozilla 0.9 (pretty much the only browser choice)
- MacOSX? Only just recently released, not quite featureful as subsequent releases, and required you to buy expensive Mac hardware.
Why don't people run these systems on VMs on their browsers (it's quite feasible these days)? Because they aren't actually as good as the stuff we have today.
This is why I quit my engineering job. I loved what I did. I hated the environments I had to do it in, and the other stuff that wasn't engineering that inevitably comes with engineering roles.
Agreed. You could be romantic about carpentry or bicycle repair or even accounting if you create the right mental framework. What strangles the romance isn't the craft itself, it's the pressures that surround it.
Yep, I gave up a software eng career 7 years ago. I always say I loved using my brain, solving hard problems and working with smart people. All the rest is why I walked away.
``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''
Alan J. Perlis (April 1, 1922-February 7, 1990)
As quoted in the dedication of SICP, aka the wizard book[0].
Unfortunately, I think this attitude is irresponsible. So many people's lives rely directly on software in one way or another that we shouldn't treat it so whimsically.
That's not to say that the practise can't be fun, but just like building a bridge we need to make sure it works.
Most people's lives don't rely on software to continue in any material way, outside of some extremely specialised circumstances (e.g. medical equipment). Just because someone's life is impacted by software doesn't mean that you should then suddenly enshrine their approval as the word of your lord. Candy impacts people's lives too, but we do not view it in nearly the same way.
this is a preposterously naive view of software. the entire energy grid relies on software, cars rely on software, all of manufacturing, the entire financial system.
Most people aren’t building bridges though. Most people are building software that just assists some business process. That absolutely does not need the same rigor as building a bridge.
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer, "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
The programmer made no reply.
Perlis was a research scientist so had freedom not everybody does.
But I have worked with people in other fields (mechanical engineering, biology, medicinal chemistry, etc) who took similar delight in their field, and it was infectious.
One can design a bridge and still have room for whimsy.
Taking a fragile system, and making it more stable can be a very exciting problem to tackle.
Taking the fragile parts of a system, and swapping them out with a more inherently stable equivalent can be even more exciting.
For example, NixOS is one of the projects I'm most excited about lately. It has a long way to go for usability (and in some ways, fun), but the inherent stability is there and working.
Because you gotta work with other people's code at some point or another. And much of it is unreliable, buggy and/or badly documented.
I hate guessing parameters for a API call, i hate debugging the garbage that my coworker installed from Github, i hate learning into some software and having it obsoleted within two years and i hate fixing the CI/deployments.
I love writing bare-metal code for the 8086 or AVR, because these platforms and their peripheral chips are well documented. I love platforms with formal standards and good documentation like C or shell script. But this isn't always useful these days.
Other people's code is why I love software. The division of labor is amazing. Even if it's terrible I can fix it faster than I can write it myself, then I can make a PR and the state of tech moves forward just a tiny bit.
I hate everything to do with devops and sysadmin work though. It superficially looks like programming work but it totally different, and often involves manually doing things that feel like they should be automated but can't quite be, or working on live systems making changes directly rather than writing code that only touches anything real after review and test.
I hate how often things get obsolete, but sometimes the constant march is wonderful. It's always great to rip out half you in-house code when your new framework does it all for you.
You can write large applications while only having to maintain your core functionality and some wrappers for external stuff.
Ahahha, fun to read this comment. I enjoy that you enjoy the exact opposite aspects of programming to me. I'm definitely in gp's camp. Always as little abstraction as I can stomach, never use a library if I only need a single function. Ruthlessly throwing out other people's code so that I don't have to try to understand boxes of spaghetti that go wrong in weird and quirky ways. I love me a good datasheet and a night spent flipping bits in registers.
I actually got my start flipping bits on the PIC, partly because I heard so much about lightweight software I just assumed it must be absolutely and objectively better in every way to get so much hype.
When IoT stuff started getting big and SSDs became affordable my attitude started slowly changing as I actually experienced more software complexity and how it could just work, and save so much time for users and devs.
The tradeoff is it only saves time if you do exactly what the library dev wants you to do, and don't look into the internals too much.
I still enjoy digital electronics design, but I don't do much outside of work because the finished product is often a bit disappointing compared to commercial stuff that usually has an app ecosystem, a warranty, an injection molded case, etc.
I've been on somewhat of a decluttering binge both physically and digitally, so I've currently got almost no DIY stuff in use at home.
Yep. It's hard to be romantic when you're trying to get a fix out for customers that really need it, but the fix has to paper over years of ahem diverse approaches to data modeling, the tests you write to help you uncover unknown abominations in your own codebase[0], every fix cascades to new fixes, it's late, dark outside, you're already thinking about how to apologize for the size of your PR tomorrow morning, and then when you finally push your branch to Github to watch the automated tests pass, it notifies you that there are merge conflicts with develop. Complicated merge conflicts.
[0] How's this for an abomination: due to an error using SQLAlchemy, one of our types was being constructed in one way in our code and being constructed in a different way by SQLAlchemy. When we instantiated it directly, you got its properties using methods: organization_id(), last_updated_at(), etc. When we loaded it from the database using SQLAlchemy, organization_id, last_updated_at, etc. were fields, not methods. Somehow people managed to call foo.organization_id(), foo.last_updated_at(), etc. in all the code paths where we handled instances we instantiated directly, and access foo.organization_id, foo.last_updated_at, etc. in all the code paths where we dealt with instances fetched from the database.
That actually could be fun. That's the pressure coming from whomever manages the project that turns it into a nightmare. Allow me however long I need to refactor someone else's mess and I'm having a field day.
I think what makes it not fun for me is seeing users screwed by things that shouldn't happen. Things we should have done right the first time. Things that can only happen because of bad technology choices. Things that take hours to fix for no good reason, things where the only reason a fix takes ten hours instead of two hours is that we're paying for bad decisions.
Transforming an old, rusty black box into a documented, smoothly-running clockwork can be a lot of fun. Truth be told, those kinds of jobs were the most rewarding I've had so far.
There's a sense of mystery when diving into an abandoned code base and deciphering the ancient scripts found there. There's the accomplishment when puzzle pieces start fitting together and the original programmer's intent reveals itself in the debris of half-decayed architecture. And then you chisel away at that, extract the beautiful core, and relearn the ancient knowledge. Sometimes there's a strange sort of historical connection formed with immaterial, long-gone programmers. There's always something to learn from those bygone workarounds and edge case traps.
Maybe I'm weird, but I love this stuff.
Much better than dealing with the hurt feelings and entrenched biases of live developers.
I really like the way you wrote about that kind of code archaeology. There's that mystery, and also almost a sense of loss when you see the ambitious hopes that fell by the wayside.
Once in that kind of codebase, I found a snippet of code that gave me a tiny glimpse of the long tuning, bugfixing, and hacking had happened on it. In a constant propagation pass inside a compiler/jit system, deep inside for a single kind of propagation, was the line:
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” - John Woods
I have a terrible memory. Sometimes I'll look at code I wrote ages ago and think "Wow! I really did a good job here.". Other times I'll think "Wow! What the hell was I thinking?" lol
Some people can maintain the complex code they write but might be viewed as spaghetti to someone else. You can't trust always trust someone's call when they say code is unmaintainable.
In the same style as the article I want to praise the gods of computer programming, who walk amongst us mortals. People who were visionaries, and move the field forward when the rest of us futz around with CRUD apps. People like Linus Torvalds, Dennis Ritchie, Stroustrup, Donald Knuth, and hundreds more.
By them, I am humbled and inspired.
And we can't forget the wars of epic proportions: the Unix wars, and fights with Microsoft & Oracle, and the birth of the free software movement. All of these shaped the current software landscape.
There's also so much to be said about the research labs where it all started...
Indeed, how can you not be romantic about programming
Isn't this so demoralizing, to be working for some company writing boring business apps.
I want to be a visionary. I have these Grace Hopper-esque ideas for how to advance developer experience.
Some examples:
1. Reading code is so complicated.
1.a. It's been 20 years since I first experienced the joy of syntax highlighting, and it feels like nothing has changed since that leap forward in coder ergonomics. We just have different colors for different bits of code, but computers can easily draw so much more than colored text. Shapes, pictures.
1.b. There are so many different ways to write the same instructions. Different developers have different opinions of what constitutes correctly formatted code.
I want tools to deconstruct and reformat code into more easily readable pieces. Really what I want is visual representations of code flow.
2. IDEs have coding auto-complete, but it's wonky. It feels like I'm in my kitchen and open a drawer to get a fork, and in the drawer is every kind of utensil ever invented by man spills out.
I'm not convinced that AI assisted coding tools are the correct path forward.
...
Perhaps this rant is just my ignorance of what tools are out there. I have to admit my experience is Visual Studio and VSCode and SSMS (don't get me started on SSMS). I haven't had much opportunity to explore what else is out there.
I think there is a lot of romanticism in computing because there is a
lot of irrationality. We don't like to admit that. We pretend to be
"scientists". Irrationality is as much the engine of progress as
reason. Both can be directed toward good or evil ends.
Ada Lovelace saw one romantic side of computing as the possibility of
machines writing poetry, music and song. Today as much fear, horror
and loathing as joy surrounds that idea - but that is also romantic in
Mary Shelley's sense. Big-R Romantic features are in both;
possibility, drama, tragedy, and rejection of reason according to a
counter-enlightenment embrace of emotivism.
Ours is the age of impossibility - the hopeless inevitability of the
status-quo, the lack of vision for alternative systems, amidst a
grinding project to render all human affairs predictable, legible,
identifiable, and controlled. Today "computer love" (the romance in
computing) derives from the struggle to overcome the ignorant,
cowering bureaucracy to which lesser men put machines in pursuit of
mediocrity and dull power.
"This is our world now. The world of the electron and the switch; the beauty of the baud. We exist without nationality, skin color, or religious bias. You wage wars, murder, cheat, lie to us and try to make us believe it's for our own good, yet we're the criminals. Yes, I am a criminal. My crime is that of curiosity. I am a hacker, and this is my manifesto." Huh? Right? Manifesto? "You may stop me, but you can't stop us all."
This exact quote (with the "Huh? Right? Manifesto?" bit) as well as mindcrime's reply is from the 1995 movie "Hackers" [0] which, while full of hollywood absurdity, has a touch of more "real" references like the quoted manifesto that give it a nice charm.
The following text, alleged to come from either one of the Zork games or possibly the original Adventure, brings me back to the original romance of programming I felt years ago. Reminds me of all-nighters with my classmates in college, death march projects back at my first job, and so much more. I wanted to be one of the Implementers. *Not one of the headless ones...
Tomb of the Unknown Implementer
This is the Tomb of the Unknown Implementer. A hollow voice says:
"That's not a bug, it's a feature!"
In the north wall of the room is the Crypt of the Implementers. It is made of the finest marble, and apparently large enough for four headless corpses.
The crypt is closed.
There are four heads here, mounted securely on poles.
There is a large pile of empty Coke bottles here, evidently produced by the implementers during their long struggle to win totality.
There is a gigantic pile of line-printer output here. Although the paper once contained useful information, almost nothing can be distinguished now.
“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.”
"Writing computer software is one of the purest creative activities in the history of the human race. Programmers aren't bound by practical limitations such as the laws of physics; we can create exciting virtual worlds with behaviors that could never exist in the real world. Programming doesn't require great physical skill or coordination, like ballet or basketball. All programming requires is a creative mind and the ability to organize your thoughts." John Ousterhout
I am romantic about it - all the classics I read - the first program in C, in Assembler, in JavaScript, PHP, Perl, Python - Charles Petzold, Stroustroup, Larry Wall - discovering procedural, declarative, object oriented, functional for the first time - setting up vim, working from the command line - gets me almost sentimental - and yet, I lost the passion, lost the drive, feeling burned out after years in the industry. I really hope I'll manage to reignite that fire. After all it's the only thing I'm moderately good at and I need to earn money to pay my bills after all. Working in the industry was only rarely living up to the sentimental romanticism you dream up as a youngster fiddling away in your past time after school. I'm working on it to stay positive - meditation is my personal defragmentation tool (those days when you could look windows - wasn't using Linux back then - over the shoulders organizing those colorful tiles - those were the days - when PC magazines came with CDs and funny programs on it). I'm not old yet really. I will have my come back. I'll show all of you. I know, I'm more than just a code monkey.
I've been burnt out from work. I lost interest in coding because I spent so much time coding for a job that made me so unhappy.
I've been able to rekindle my passion for coding by finding personal projects to work on. I like to build utility apps, or screensaver-like art experiments. It's fun to learn something new. I once wrote a art project using CSS transitions, then rewrote it using a Canvas element. It was interesting to see the way coding was different in each situation. I never realized how much heavy lifting the web browser's CSS engine does until I tried to crossfade a colored square in a Canvas.
Also: Are you old enough to remember magazines with printed source code that you would have to type in manually? I remember finding them in my parent's basement among their science fiction literature magazines.
There's writing code that you want to write, code you find interesting to do something you care about. And then there's writing code that somebody else tells you to write, that you have to do for a job. Those are different things. I'd imagine most of us started off spending lots of time on the former, and now instead spend most of our time on the latter.
I read the article and I still can’t help mis-parsing the headline. The author meant “programming is a romantic activity”. I read “how can we overcome romanticizing programming?”
Maybe it’s just my perspective. I used to be in love with programming. But doing something I loved as a job left me open to burnout and vulnerable to being used.
Now I’m not “in love” with programming. Partially because it doesn’t intrigue and surprise me like a new lover does. We have a comfortable relationship, we’ve settled down. I’m married to programming and it’s work but it’s worth it. There’s still fun and fulfillment, but I’m not infatuated like I used to be.
Just a correction. The fat guy wasn't from his team, he was from some other team. And he didn't fall, he jumped down onto the first base because that's what he was only barely able to do, he knew that in the best case scenario he only have like 50% chance for the first base because he run so slow.
So basically his tactic was: if I run as fast as I can I have 40% to reach first base. If I run as fast as I can and jump I have 50% to reach first base. He didn't even consider going to second base, ever.
That function is the heart of the page allocator inside the Linux kernel [1]. The fundamental building block for every memory allocation on any system (running on Linux). Whether you call malloc() in a C program, kmalloc() inside a kernel driver, the new operator in C++, load a file in python, or almost any other operation, it will ultimately end up in __alloc_pages() (for small objects, multiple units will share a single __alloc_pages(), then there is a fine grain object manager on top of that such as Slab/Slub, jcmalloc, tcmalloc, mimalloc, etc. but you got the point).
very cool. i recall in one of my classes at unversity (i did a compsci degree) we used nachos (https://en.wikipedia.org/wiki/Not_Another_Completely_Heurist...) and i have vague memories of implementing some kind of virtual memory system with a page table. i also did a microkernel message-passing rtos for the i386 in another class but if i recall correctly, that particular os didn't have to support dynamic allocation (or maybe i have forgotten - it was a long time ago). i am not sure how useful such a limited system would be in practice.
thanks for the information. i am a high level programmer by trade these days, but given enough free time, i think that it would be fun to learn about the internals of the linux kernel in some depth. frankly, it intimidates me a bit (perhaps it should, im not sure).
I love this. Programming is so much fun. Even when my work means I don't program for work any more (which inevitably happens) I continue to do so recreationally.
I'm really sad for people who chose the field just for the money and are miserable about programming. I hope it works out for them, but that's no way to live.
The final two paragraphs once again remind me of the Programming Sucks[1] Blog entry I've reread several times.
It's almost mood dependent whether I look upon on the systems we've created or in fondness or in anxious peril. I still love this career, but with some recent burnout occurring I often find myself quipping "Technology was a mistake".
There's absolute beauty in code. There's also absolute despair at times. I wonder if things will ever become more rote or structured in my lifetime, or will we be constantly pushing the envelope, hardly looking back and just barrelling ahead, pitfalls and all
I'm more cap R Romantic I guess. I center myself on my relationships to nature, the universe, human connection. Computers and the code they run are as romantic as a pencil: I can focus on it and where it came from, what went into it, what it can do and I can feel awe at what we've achieved together and what we can accomplish with the products of that. But I don't feel any particular way about the pencil itself, nor more deeply connected to the things I really value for having contemplated it.
I love being part of it. My fear is losing it but I suppose even in a not well off place, there will be a computer somewhere I can use and work on. I just like tinkering, making things. Seeing it go.
It is romantic to pursue a hobby for the sake of it.
That said, work is not romantic.
All you did is fuck up a good hobby, look at it, it's got deadlines.
Is that worth it? Probably, it makes a decent living, but work ain't romantic.
That's why people get disenchanted with programming (and with a lot of other things)! We love to do the actual core activity. We love it so much we do it for free. You get paid for having to deal with the pressure to succeed. And you get paid for having to do all the other stuff that comes along with it.
Its the other stuff that grates on you until you hate it.
[1] https://youtu.be/-Ythtg8ZVbY?t=166