Great write-up on that subject is in the first chapter of "Mythical Man-Month". Here is small excerpt.
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 re- moved from pure thought-stuff. He builds his castles in the air,
from air, creating by 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. (As we shall see
later, this very tractability has its own problems.)
...that has nothing to do with the problem in my opinion.
Yes, programming is fun in general but then you come in touch with the reality of the job only to find out once again that
1. you are not making things, most of the time you maintain some old crap because nobody wants to spend time and money on building a new better version etc
2. The thing you are working on is useful but you can't really tell how. The damn thing is so big that all your input after years of work is almost invisible to anyone, even on your team
3. Library here, framework there and most of your own code is just a clever way of putting them together. Fascinating at the beginning, a boring routine a few years later
4. okay, sure, that's enjoyable, sometimes too much.
5. Again - works in theory, breaks after the next meeting. "No time to rework and polish. It works somehow and generates money, so go help those guys finish their work. Bad architecture? Hard to maintain? No matter, management sees only frontend anyway"
Yes, I've started doing personal projects as a therapeutic exercise.
My personal projects used to be about the end goal: making something that I want to make but don't get to at work.
Lately they've been more about the exercise: the sheer pleasure of writing code that's my own, that will always be my own, that works well and all lives in my head, even if what it actually does isn't especially new or interesting. It's like a digital zen garden.
I feel like this sums it up pretty good for me. Even today when I get challenged and have to come up with a clever solution, I'm enjoying it but 90% of work is fetch data, show on front end, user edits, save in database.
I have been working on a large project for over 6 months now, 30k lines of code.....it still feels like I have not done much.
Work on small projects. I'm writing all projects myself and it's still fun, when you decide everything. I can write my own HTTP server implementation if I feel like it.
I do plan some side projects to do in vanilla JS, which should be more fun. However, at work I'm working on a significant project, and it can become a real drag.
It does have to do with the problem. Your points only go to show why people grow to hate coding despite the enjoyment it once gave. My own suggestion is to try to create something not for money or fame but simply because you think it is good and take whatever time you need on it.
And the rest of the book deals with why it is more often than not painful. In summary, it's complexity. Brooks argues that software, being a pure thought-stuff, is also the most complex thing we attempt to build. And it's even worse now than in his time with any concern for quality taking a back seat in the face of competitive pressures. So it's not really surprising that slapping together ever more complex systems out of ill-fitting, purely-designed components is not fun.
After taking a break from software side-projects to work on more physical things (woodworking, metal-working, welding). I have to agree that software is one of the most complex things we work on. Even something quite complicated that's evolved over decades, like a car, is largely comprehensible to a single person without an enormous amount of effort (i.e. many people understand how every single subsystem of a car works), while understanding everything in say linux or postgres takes a much higher level of effort (it can be done too, but there is a lot more complexity to keep track of).
It's so weird to me that software's complexity is such a force of nature.
My instinct is that no implementation of a piece of software should ever need to be more complex than the idea of it is (fully and precisely articulated, of course). Yet the code is usually orders of magnitude more complex than that. I don't understand why we can't solve this problem.
The paper "Out of the tar pit" (https://github.com/papers-we-love/papers-we-love/blob/master...) discusses this in more details. Basically it argues that one needs to separate the complexity into essential complexity (complexity inherent to the problem) and accidental complexity (complexity due to the way the solution is designed). The idea is to reduce accidental complexity as much as possible while making the essential complexity more managegable.
The paper also discusses that you can separate a program into
1. state (data that changes over time)
2. behavior (computational logic)
In order to reduce the accidental complexity, you can use functional programming (which is purely behavior, devoid of complexity due to state mutation) for the behavior part. For the state part, you can use a relational database to manage it in a more systematic manner. They call it functional-relational approach to software design.
If you do game development, you likely heard of ECS (entity-component-system) and data oriented programming which in a way promotes this approach to software design.
Such a great quote. I think the thing is that people weight these "joys" differently. I know that for me the learning part is probably the most important: I love the feeling of becoming better and getting a deeper understanding of unfamiliar systems. Doing the same kind of coding for decades in the same language seems very dreary to me.
On the other hand, the "making things that are useful to other people" is not that important to me. I mean, it's nice when the stuff I make is useful to other people, but it's not the primary thing that makes me love programming.
So, I think the thing is that you need to figure out why you loved it in the first place? Is it "joy of learning"? In that case: go find a weird new programming language and dive deep into it (become one of those weirdos that think everything should be made in Haskell or Prolog!). If on the other hand you like making things that other people find useful, go look for open source projects you can contribute to. Think deeply about what it was that made you love programming in the first place, and what parts are missing now that existed back then.
I find this fascinating. For me, the lifelong learning is a chore, completed in order to do what I love: creating things.
And watching people use my creations to do things they couldn’t before is a reward on its own. I imagine it’s like a teacher watching their students apply their lessons in daily life.
I completely agree on everything said. I think we all need some personal projects to give us creative freedom and let us do things the way we feel they should be done without inhibition. When I was making https://mockadillo.com, I made all of the choices I wanted to make, vanilla JS, simple interface, no unnecessary bloat, and I loved every moment of making it.
20 years is a long time in anything. My first piece of advice is that nobody here knows who you are, nobody here knew you as a teenager, and nobody is going to understand what "love programming" and "don't enjoy it" actually means for you. The point is: anybody who claims that they got de-burned-out with this one trick isn't necessarily dishonest or naive, and if something in the comments here resonates, then by all means try it out. But they might be offering a good prescription for the wrong diagnosis.
This may sound dismissive or condescending and I promise it isn't my intent: have you considered speaking with an actual therapist? As a society we tend to think of therapists as something you do when you're mentally ill, but you don't just go to the dentist when you suspect you have a cavity: mental hygiene is important, and humans are universally bad at self-diagnosis, either physiological or otherwise.
In my current job I write Python, which I really don't like very much and I get burned out on Python-specific things. But I know my feelings of burnout are due to things that would be true regardless of the technical environment - and that an overall job with Python is far preferable to my previously miserable job with F#. And there's a lot of non-job stuff going on - such as the historic pandemic, and domestic stresses from being cooped up at home.
So speaking with a therapist about what's actually eating you might be quite worthwhile. If it is just burnout with programming, there really are specialists out there who might give well-informed, non-anecdotal advice. If it's something else, then having a professional suss it out means you can make better decisions about major aspects of your life. Plus, therapy is something that's easy to do over videochat. I am not recommending therapy, but I do think you should consider it.
> As a society we tend to think of therapists as something you do when you're mentally ill, but you don't just go to the dentist when you suspect you have a cavity
I started seeing a therapist about a year ago and went through a similar mental switch. I used to think of them as, like "mind doctors" to fix you when something is going wrong. But now I realize therapists are much more like personal trainers for your mind.
I'm not mentally ill or suffering any particular crisis and I still get a ton of my therapy appointments. It's basically an hour with a really smart person deeply trained in psychology who helps me make the most out of my particular brain and personality.
Sorry to change topics, but are you able to expand a little on what made F# miserable. I ask as I was looking at learning it in the hopes that it would provide a positive developer experience. I would be very interested in finding out why it didn't work for someone else.
Hopefully OP will response. I read ojna's post to mean that he prefers F# over Python, but that the rest of the job around the F# programming was miserable (maybe biz, org, process, and personality stuff was bad).
(sorry for the late response, I try to avoid social media of any form...)
I love F#. F# is by far my favorite programming language when it comes to writing enterprise software.
The problem with the F# job was that many on the sales team, and in upper management overall, were just bad people. They were a bad influence on my boss, the CTO and an otherwise good person. I ended up resigning over an ethics dispute.
I'm also not trying to sound dismissive or condescending, but it really seems weird to me that if somebody says they are have been doing something for 20 years and now they are bored of it, then they should consider seeing a therapist?
I mean, there are plenty of things I used to like that I don't anymore, should I go see a therapist every time my interests change?
I think it's more about your intent. I'm not too bothered I don't care about soccer any more, I'm not after therapy to change that.
In this case though, I see someone who badly wants to be enjoying programming, but for whatever reason they don't understand they don't. It's probably a good time to talk to someone. Usually I'd start with my girlfriend, maybe my mum, perhaps take a few weeks off and then see how I feel. If that doesn't sort it, I'd probably want to talk to a therapist.
It's true this kind of stress and feelings are universal, but doesn't mean it's not a potentially serious psychological concern. Parents who feel extremely overwhelmed with lots of young children in the house are understandably stressed out - and yes, should be encouraged to consider therapy to help them manage.
I would recommend reading munificent's comment above about therapists as "mental trainers." I think everyone should consider seeing a therapist at least at some point in their lives. The idea that therapy is only when something is medically wrong is at best misguided and at worst dangerous.
When I suggested OP considers therapy, I didn't mean "uh oh, sounds like you're clinically depressed, DSM-V states that a loss of interest..." And the word "consider" is doing a lot of work there. OP's brain is clearly trying to tell them something, and having a knowledgeable certified professional to talk things through with is simply prudent when it comes to something as profound (and risky) as reconsidering your career.
Careers are not cast in stone. Some people do change their careers if they realize that there's something else that they'd really rather be doing with their lives.
I've met an artist who became a doctor, a lawyer who became a stockbroker, a software developer who became a full-time professional musician, a professor who started a hedge fund, etc.
On the other hand if you are changing field because you are unhappy with your current situation it is relevant to ascertain that your current field is part/cause of the problem.
>>> In my current job I write Python, which I really don't like very much and I get burned out on Python-specific things.
I've used Ruby for several years, and I love the language. I wish I could use it today, in my daily stack, but unfortunately, Python won in the marketplace.
Syntactically, Ruby and Python are pretty much equivalent, with Ruby appealing more to me. However, Python won - no arguments. Got to go with the winner.
I've been stuck on the horns of this dilemma for a while, at least for choice of a scripting language. Ruby and Python adoption is pretty similar if you're working in web devlopment rather than data science. In London the number of Rails and Django jobs is fairly equal. Agree, though, Python is racing adhead of Ruby in general and that makes me sad.
From what I've seen, specifically-Ruby jobs tend to pay more than specifically-Python jobs (and more than specifically-Java jobs, for that matter), and while Rails and Django seem kinda balanced in some areas, in others Rails beats the tar out of Django for startup market share.
There's an iceberg of Ruby jobs that don't exist in the most obvious places to search, and because other languages have gained more spotlight (including anything that even smells of ECMAScript) there are fewer people searching for Rails jobs so the number of Rails jobs is pretty well matched to the number of job-seeking Rails devs. Also, early stage startups tend to hire from people they know, not from job search sites. Finally, there are many "full stack" jobs where work on the backend means Rails.
A simplistic metric like "job listings on angel.co" (especially if you're specifically looking for Rails in the job posting title) don't tell the whole story.
Use the right tool for the job. If "the winner" was all that mattered, we'd all be using Java now, and it would remain the top language forever, as long as it makes any sense at all to use -- not even requiring it to make more sense than other options.
Technological progress often evolves as a Scale Free Network[1] where the nodes with most present activities are likely to see the highest investment.
It is less of a problem for mature ecosystem and tools, but being in the "not winner" position will likely induce negative effects in the long term technological progress. (I am sure there are many counterexamples)
If we assume, basically, that only The Winner Language should ever be used, we either end up with a long-term glut on technology churn (e.g. JavaScript's miserable state of instability right now, but for everything and not just JavaScript) or rapid development of novel forms of mediocrity (Java), and nobody should ever bother with Python, in which case the previous commentary still makes no sense because Python isn't "The Winner".
Sufficient investment for significant ongoing value is a matter of a threshold relevant to the particular needs served by the target technology, not of rank. As long as there's "enough" interest, it will have as much likelihood of stable or increasing value for (appropriately targeted) users as anything else.
Meanwhile, too much investment from too-big interested parties can ruin something pretty thoroughly.
Things are not as straightforwardly popularity-contest-driven as you seem to suggest.
> Things are not as straightforwardly popularity-contest-driven as you seem to suggest.
Popularity contests are not simple.
Programming is an huge field comprising many unsyncronized industries and fields. Each of them can have its own winner (or winners) and they interact in complex ways. How is beyond the point.
My claim is that having the most mindshare/resources is the simplest way to keep having the most mindshare/resources. Few technologies rely only o this to stay alive, but a relevant factor is that differently than many other (often technical) advantages this one has a positive feedback loop.
Coming back to the original topic, this might mean that even if you invest a lot in the "best" tool to solve your problems it is possible that the lack of ecosystem around it (due to other people choosing "worse" tools for the same problems) makes it a losing investment.
Of course things are not linear and even the best interpolations have only intervals of validity, yet general long-term trends and cycles exist.
If you want you can add a rate of decay to the weight of nodes in the model, but the point remain: resource distribution is typically not fair in any a priori sense; often it simply scale with the already available resources.
Example: Bitcoin is the among biggest cryptocoins mostly because it was the biggest at some point.
> My claim is that having the most mindshare/resources is the simplest way to keep having the most mindshare/resources.
That's largely true. Of course, having "enough" mindshare/resources is plenty, generally; one needn't necessarily have "the most". I don't see Ruby or Rails going away any time soon, even if your local area's angel.co listings show a 40% higher rate of job postings that explicitly mention Django in the headline. Development is still quite active both on, and with, the language and the framework.
> Coming back to the original topic, this might mean that even if you invest a lot in the "best" tool to solve your problems it is possible that the lack of ecosystem around it (due to other people choosing "worse" tools for the same problems) makes it a losing investment.
If your choice is Smalltalk, that might be true. If it's actually a very active community around a language and framework that provide extremely good productivity support and a lot of advanced tooling constantly attracting more innovation and heavily used in some sectors, like Ruby and Rails, it's not so true. There's pretty much guaranteed (absent government-granted monopolies) to be quite a bit of diversity in "popular enough" languages and tools for any high-traffic development sector, and "startups" definitely qualifies as such a sector of development as a field of professional work. The "winner" approach you seem to want to champion would have room for basically two options, and both of them have "Java" in the names of their most popular implementations, so arguing about the relative popularity of a Python framework in one corner of the world is irrelevant at best given your evidently intended thesis.
> Example: Bitcoin is the among biggest cryptocoins mostly because it was the biggest at some point.
This is a good point, but does not address the fact that this doesn't mean discounting Decred or Monero as a terrible choice for any useful timescale is the obvious best option.
Ruby on Rails is more popular in some areas than Django. Ruby on Rails gets a lot of time and money investment. Ruby on Rails is likely to be a good, stable choice for years to come. That example illustrates the fact that always choosing "the winner" doesn't make sense if "the winner" involves choosing the second-worst tool for your specific job out of a field of a dozen or more available tools.
Feynman described his run-in with burnout, you may find his experience interesting. I quoted a piece below, but the book is more persuasive with more intricacies of his situation.
Then I had another thought: Physics disgusts me a little bit now, but I used to enjoy doing physics. Why did I enjoy it? I used to play with it. [...] So I got this new attitude. Now that I am burned out and I’ll never accomplish anything, I’ve got this nice position at the university teaching classes which I rather enjoy, and just like I read the Arabian Nights for pleasure, I’m going to play with physics, whenever I want to, without worrying about any importance whatsoever.
[0] Surely You’re Joking, Mr. Feynman!”: Adventures of a Curious Character.
I went through something similar, a bit earlier in the process. I wasn't burned out with programming, but burned out with the particular job I was doing, which had basically been taken over by the work of being a maintainer: Reviewing other people's code, writing up community standards, trying to relieve friction in the community, etc. I had programming things on my to-do list; but whenever I organized the list by order of importance, the programming tasks were never anywhere near the top.
I reached the point where I'd sort my list, look at the things at the top and think, "I know these things are important, and it's certainly gratifying to have the influence and the authority to try to make these changes... but I kind of don't really care."
At that point, I realized that if something didn't change I was eventually going to get fed up and leave the project entirely, leaving a big hole. So, I said that I'd set aside Friday to do some "fun" programming, to keep the job interesting. (I ran this by my boss, and he was supportive.) I thought this "fun" would have to be something really different and new, but it turns out nearly any kind of programming will do; so although I mentally give myself permission to do whatever I want on those days if I need to, I often end up just writing "normal" "important" code from the top of my to-do list. Just that little bit is enough to "pay" for the rest of the week.
Joy is the source of our power as human beings. No human activity is sustainable long-term if the psychological cost of doing something outweighs the psychological benefit; and conversely, people can endure an amazing amount of hardship and toil if the activity is a source of joy. The key to sustainable work, relationships, whatever is to be looking for ways to find joy in those activities.
This is very insightful. I find that having to have a "reason" to code kind of takes away the joy of it. I.e. I start to think "is this useful?" or "is this a waste of time?". At that point all the joy is sucked out of the atmosphere and I end up doing work instead, which is very little fun most of the time.
Time you enjoy wasting is not wasted. I often need to remind myself of that.
Great book and a very relevant story. Read up about Feynman and his depression after being involved in the Manhattan project, and how he overcame that by 'playing' with the wobbling plate problem.
Imagine what a mind-fuck it must have been to be on the Manhattan project! They probably wondered if they would be responsible for the end of humanity...and I guess the jury is still out on that one.
Programming is 1,000 room hotel of which we live in only one.
I recommend you study different programming paradigms because in them we can find really interesting approaches to solve problems.
For me those have been:
- functional programming (with Haskell)
- logic programming (prolog)
- Constraint Programming with the excellent Coursera class on minizinc.
Those paradigms made programming fun again for me.
PS: I also stay away from JavaScript... When I was working with JS.. I was seriously considering leaving programming... Thankfully I changed jobs and I haven't had to touch it anymore.
Jumping in this post to recommend the exact same idea. Learn a new language outside the type of language you're used to using. I've been using my extra time indoors to learn Clojure and Forth. The things I'm learning are already changing the way I write Swift. I'm also excited about making things on microcontrollers again because Forth gives me a way to escape the horrible tooling forced on us by the chip manufacturers.
It's hard to explain, but no other language has given me such joy in perhaps decades.
If you look back on those times where you just had a booklet and a simple BASIC interpreter or C64 Assembler crafting your tiny little applications and games without third party libraries, distracting ceremony and best-practices anxiety. Those times where you could be so proud of every little achievement because it was truly yours, and that for some reason felt your most productive years... Then you might want to give it a go.
Just don't fall for the trap of developing your own Forth. Even if that's part of the philosophy of it :)
Now I just wished there was a book akin to "Land of Lisp" but in Forth. Maybe one should...
Besides trying out new languages and paradigms, I would also suggest programming things of a kind different from what OP's used to. For example, if they mainly do CRUD webapps at work, maybe they can start looking into creating games, a language, (programmed) music, screensavers, etc. Whatever they think is cool. It doesn't need to be big.
Couldn't agree more with this. After 15 years of OO with Java/Ruby/Javascript I switched to Elixir and Elm and have really enjoyed not just the freshness of something new but the elegance of the more mathematical approach that functional programming leans on. 3 years on and I'm enjoying coding more now than I ever have.
As someone considering leaving the web development industry after 12 years:
JavaScript is a never ending grind.
Callbacks, then Bluebird, then Promises, then a sync await.
a new testing framework every six months. a new web framework every couple of years. aimless, massive changes to the language (classes in a prototyped language? Why not).
JavaScript then coffeescript then three versions of typescript. too many UI libraries to mention.
JavaScript on the server? the people making the most popular web framework abandoned it 5 years ago but who cares?!
paradigms that make no sense (react morphing from a UI library to the full app). a million ways to manage state.
then you have a few big players calling all the shots (FB, MS). I guess we use functional components now. Eurasia has always been at war with Oceana.
It’s tiring. I’ve spent my entire career doing this stuff; and I’m never quite good enough before The Next Big Thing comes along.
I know things change over time everywhere, but it’s hard to imagine anything moving faster with less purpose than the JS ecosystem.
(Apologies for typos and grammar; I’m on my phone)
It's like you have to constantly keep learning, but nothing you learn really matters in any deep way. It's just new names and APIs for the same stuff, month after month.
Imagine if you were a woodworker making furniture. You make the same furniture every day and love your craft. But every month, someone shows up, takes all your hand tools, and replaces them all with a set that are mostly the same but slightly different and all have completely different names.
1000x this. One of my pet peeves is the idea that all learning is equally worthwhile. It's possible to waste one's life "learning" the inane and shallow, and it's a suffocating experience when it happens.
'JavaScript is a never ending grind' - Wow no better way to summarize it than that. The funny thing is that I've always felt that Javascript the language is pretty straight forward and easy to comprehend. As someone who primarily writes Ruby and really appreciates the functional style of writing code, Javascript lends itself to that style very easily.
But the ecosystem around is just that never ending grind. At my last job, over the 3 or so years I was working fully stack, it was just a constant churn. Start with React / Redux / SRR / Jest / Mocha / (probably some other testing frameworks) / Flow. By the end none of the original testing frameworks were being used. React had introduced Hooks, which I actually like, but it was a whole new paradigm to learn again. Flow was out and we needed to migrate to Typescript as quick as possible. And this is just the React ecosystem!
React has its place and I'm definitely comfortable working with it (also writing 0 tests cause I have no idea where to even start for that) but I'm looking forward to the day maybe simple web apps get back to simple setups. Projects like LiveView[0] for Phoenix really give that hope.
>I've always felt that Javascript the language is pretty straight forward and easy to comprehend
While that's true, the completely opposite is true for Javascript the ecosystem.
I don't have much time for this cr*p, nor do I like it, so I tend to use olde fashioned JS + libraries like jQuery for old fashioned multi page web apps. I want to learn Blazor and Vue for SPAs to keep it more simple.
A lot of this is a direct result of feeling that one always needs to be on the bleeding edge, which is both unnecessary and also a recipe for wasting time on fads.
As an analogy, consider fiction. Imagine reading as many new novels as possible as they're released. Well, most of these novels will be completely irrelevant 5 years from now. The good ones stand the test of time. So you might as well only read novels that are 5+ years old, yet are still relevant and receive acclaim.
If you worry that taking this approach with JavaScript will make you fall behind, my question is: Behind whom, exactly?
There's no way many in the industry can keep up with all the changes you listed as fast as they're coming out. Therefore, it follows that a great many of your JS developer peers are "behind." Therefore, it's okay for you to be, too.
What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows. Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest. The result is that I end up skipping a lot of the fads that die on the vine. For example, I largely missed CoffeeScript.
I think a lot of pain from JS comes from the expectation that one can and should keep up, when you probably can't, and definitely shouldn't.
> A lot of this is a direct result of feeling that one always needs to be on the bleeding edge, which is both unnecessary and also a recipe for wasting time on fads.
The problem with this is that everyone jumps on new fads so quickly that, if you don't, you're likely to endup with a bug-ridden, half-baked, vulnerability-riddled, unmaintained/abandoned, slowly collapsing, termite-infested framework as the basis of your entire SAAS business, or whatever it is you're trying to run on something that even the creators abandoned for the next fad.
> What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows.
You have to be very, very lucky to accidentally end up with a "pretty recent stack" that will still be maintained in five years. On the other hand, the next part shows that you don't actually go with the 5+ year old "stood the test of time" tools:
> Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest.
Having to learn a whole new sub-ecosystem in as little as two years is exactly the kind of mind-destroying grind everyone's complaining about. I don't think anyone's just jumping on the newest thing that appears every six months; they're all just having to move to some new toolset every two to five years and burning out ten years into a career because otherwise they'll end up having to be the new maintainers of whatever tools they're using due to the fact nobody else is using them (and thus no one else is maintaining them) any longer.
Oh, yeah, and if I have to learn a whole new fucking sub-ecosystem and new version of the language itself with a bunch of breaking changes every two to five years, I don't have any time to spend learning fun things like a whole new language designed around a whole new paradigm.
ECMAScript and everything that touches it has become an actually focused bane for the joy of programming. It was fun just writing some clean plumbing for JavaScript applications in the past, but everything else about the process always ended up involving a bunch of scrambling to catch up with rapidly changing technology, planted on shifting sands even while I'm working with it, any time I start on a new project, where all I'm learning is a new set of persnickety conventions that will punish me if my approach is "wrong", force new work-arounds on me, and generally suck up all my time learning new rules to follow instead of interesting new ways of thinking about things that make me a better programmer and software designer.
Learning the interesting stuff, and figuring out new approaches to new problems based on the needs of those problems (and not the whims of the community), is a lot of what makes programming fun for many of us.
Linux exhausts me similarly.
* ALSA; esound; PulseAudio; etc. Just give me updated OSS or sndio on a BSD Unix system. That shit is stable, well-maintained, and not arbitrarily different every few years.
* SysV; upstart; systemd; etc. Just give me BSD RC. Maybe it's not ideal, but shit, it isn't swallowing 80% of userland with eventual ambitions of conquering the kernel and some of the worst defaults I've ever seen.
I'll just stop now, but I could go on for days in this vein. Maybe some of these tools are great, but I don't expect any of them to remain ascendant for more than five years in a form that is effectively recognizable by any significant measure but its name. The churn drives me insane. One of the reasons I aimed for software development in my professional life, abandoning the system and network administration (aka "ops") side of thing, was to escape all that crap. I want to write quality code, build new things and improve existing things, not participate in a rat-race to remain relevant just to have acquired nothing enduring from decades of effort other than stock options and a nice car.
> A lot of this is a direct result of feeling that one always needs to be on the bleeding edge, which is both unnecessary and also a recipe for wasting time on fads.
It's also because the JS ecosystem is absolutely massive -- too massive. Instead of consolidating around a good package, people create a new one. You end up with a small number of contributors (often one) per library, and being on the bleeding edge is the only way to make sure your dependencies are maintained.
Lack of standard library doesn't account for web framework churn, though. Momentarily seemed like we had coalesced around Vue and React, and here comes Svelte, among others. It's incessant.
React was released 7 years ago in may and is definitely the most dominant framework and going very strong, and will be a good career investment for years to come. I think framing that "momentarily" for yourself is making yourself very unhappy - life changes constantly, as we see with this pandemic, and we need to have a little bit or willingness to accept change every five years or so, or perhaps we need to choose a field that has less competition (which is also why we enjoy great benefits and great pay). It should also be noted that both Vue and Svelte are extremely similar paradigms to React, and not at all the big paradigm shift that we saw from Angular to React.
I'm one of those "weirdos" who loves writing JS, and yet I agree with everything you just said being horrible. But I enjoy writing plain JS, that doesn't mean react, angular... i've run out of examples because I honestly don't care about those things.
However, I'm in a position where I have enough autonomy to avoid all that crap and just use the bits I like. When you get minimal and ignore all of the noise about the latest hotness JS libraries, the plain language (not including the lanky browser APIs) is not unpleasant especially over the last few years where some modern syntactic features were added - You can go even further and be selective of the language itself and it can get even more pleasantly minimal, my recent delight has been excluding classes and prototypes as much as possible.
When you take this approach the whole "churn" issue disappears (JS is backwards compatible, you will never have the issues you have with Rust or Elm forcing you to re-write).
I suppose this is the argument many make for C++ which is that, yes it can be a complex nightmare, or (if you are able) you can restrict yourself to a desirable subset and have a happy time. In JS's case, most of the complexity is from "keeping up" with the community and libraries, not the core language itself.
I enjoyed the hell out of writing application plumbing, but the moment it started turning into an actual application that interacted with the outside world I was dealing with the hell of the Node ecosystem of "compiling" and packing for the browser, framework crap, buggy testing libraries, and all the rest of that nonsense, with an acutely clear understanding that all of it would change in five years and I would have almost zero useful knowledge from the tooling and ecosystem experience of the preceding half-decade.
In the mainstream professional JavaScript world, my advice is to escape as quickly as you can, and pursue things where the learning focus is on more interesting things than the arbitrary whims of the authors of half-baked (because they never have time to mature before they die) frameworks. If you can just live on the fringes and write JavaScript your way and not worry about constantly impending obsolescence of your entire technology stack (from Linux all the way up to your JavaScripty CSS framework), though, I'm sure you can have a great time doing it.
I'm writing a lot of C and Ruby these days, and I love it. I get to learn more about myself as a programmer, instead of more about other programmers as fly-by-night framework developers.
I'm not really sure what you mean by "constantly impending obsolescence", but as one anecdote in the face of that: I have plenty of core JS code in production that was written 3-4 years ago. I've gradually improved or changed parts of this codebase but that had absolutely nothing to do with external libraries of which I use very few... this feels very unchanging to me, my code is not about to implode due to any external reasons.
I write my own UI/MVC type code from scratch just because that's the way I roll and my requirements there are a combination of minimal, extremely performance sensitive and in many cases esoteric where I have to write the UI anway so it's not much work compared to forcing existing libraries to do what i want... but if had to I could replace it with some hip and upcoming UI + MVC library and still keep 95% of my core code completely independent and intact.
I think JS world feels like massive churn if 90% of what you are doing is UI UX etc, because that's the interface that can never sit still in the name of progress... either that or you (not you necessarily) are doing it wrong and not separating UI code from your application code (I've seen this happen quite a bit in ye olden angular days where everything becomes attached to angular for no apparent reason, and angular itself is the worst of OOP + MVC where everything is convoluted and difficult to follow).
If you're basically building everything from scratch, of course you aren't going to see the churn as much.
If you build on others' frameworks, and those frameworks drop out of maintenance because the maintainers moved on to shiny new things, any security vulnerabilities or emerging incompatibilities with browsers can quickly prove ruinous for people who used those frameworks.
I wrote a SPA while working at a consultancy. It was actually pretty churn-proof the way I wrote it, but during one vacation day and the following weekend a couple people (including the boss) just rewrote the whole thing to use more faddish framework stuff. I don't work there any longer, but since then (about 2016) they've probably had to effectively rewrite it twice if they kept up with that approach.
That's what I mean by "constantly impending obsolescence".
Maybe I haven't been doing this for long enough (~8 years), but I think we're starting to see a plateau in JS-land.
I jumped into React early-on (5 years ago), and it's still going strong, and has been for way longer than Angular / Backbone / ExtJs ever did.
I wouldn't say Express is abandoned, I feel it's more that it's "matured". I mean what else can you add / improve?
State management is still an un-settled area; 2 years ago it seemed like Redux was the best choice, but GraphQL / Apollo is eating its lunch. However, when you think about it it still follows a similar conceptual model, but making it even more declarative: You have your "store" (the query result), and you dispatch "actions" to modify that store (the mutations). You just don't have to dispatch an action to fetch data from the server anymore; Apollo handles that for you.
It's true that JS churned very fast for a long time, but I'm seeing signs of it slowing down as problem areas become "settled" one-by-one.
I've been programming professionally for 20 years and doing exclusively frontend with React since about 2014.
After the whole React Hooks thing, I can't freaking wait to do something else; and I'm absolutely livid with their decision to promote Hooks.
They should have forked React instead of introducing that into a somewhat mature ecosystem. Already went through this fractured bullshit with Coffeescript, and a million other frameworks of the moment. The JS community just doesn't learn, and when you see a big player like Facebook making the same mistakes, there really isn't much hope.
I've found that this grind is conquerable. There are only so many ways to go before you start to see the fundamental patterns, and friction in picking up anything new becomes seriously minimal. It's like how some other comments are, talking about how most of programming is really just data access and some clever gluing of frameworks. Or like how there are already software patterns, especially in OP.
My point is, you start to glimpse these overarching patterns as you interact with different takes, and you learn what works and what doesn't, ultimately empowering you to intelligently make tradeoffs or designs of your own. The chaos of web development is, IMO, because it was a new frontier, and a lot of inexperienced leadership occurred. This was compounded by bootcamps churning out people experienced only in Framework X, causing poor re-implementations of nearly _everything else_ inside Framework X.
It sounds like you feel like you _have_ to keep up with these things - perhaps someone else on the team is constantly insisting on migration, but they don't have to go through and tediously migrate and test everything. I'd suspect this lack of autonomy is at the core of your dissatisfaction. You can, and should, say no to a lot of trends, and if you do pick up something new, you should be able to clearly articulate why it's valuable, and these values should be more than superficial.
Another thing worth noting is that the release you work on today is the "legacy, painful" code of tomorrow. But that's a good problem to have - it got the job done. It just happened to get it done in one way, when there are really N ways, and so obviously the numbers game will work against you eventually, even in the imaginary case where the implementation is perfect.
I can't empathise with it being a grind - keeping up with the latest developments only makes sense if you need to for your job or the new thing brings something genuinely useful.
However, JavaScript as application code just feels entirely verbose. I guess coming from a very opinionated framework like Rails leaves you sheltered, but I'd rather use a technology designed for the task I'm trying to accomplish than to shoehorn JS into something else.
Personally I find no elegance in JS, and writing it feels like a chore. If I had to do that daily I'd want to quit too. Obviously YMMV, but I get no joy in trying to fit the tool to the job, I'd rather just use another tool.
One of the reasons it's so popular is because JS is like Latin. If you know some words from one Latinate language, you could blag your way around half of Europe, probably order a meal and find directions. If you know some JS syntax, you can scrape by using half the tools out there today, and accomplish a bunch of different things.
If you want to go and live somewhere though, it's better to learn the native tongue.
I was a game developer and I pretty much grew to dislike what I had to do at my former job. Doing same kind of mindless games, over, and over and over and pretty much repeating things.
I got into web development, but for me that means mostly back end.
I pretty much dislike big opinionated JS frameworks like Angular, although I have to learn it and I will since I took over a project which uses Angular on front-end.
Sometimes I generate HTML on the server side, when I can, using a bit of old fashioned JS and jQuery where is needed. Sometimes I write a REST API for backend and write the frontend using good old fashioned HTML, CSS, JS and jQuery. I like this two approaches the most.
Now I'm planning to learn Blazor and Vue for SPA development.
Well said, I was close to 8 years in web development and jumped ship a little over a year ago. Working in javascript development felt like a hamster wheel but maybe I just needed something different.
I felt exactly the same thing the last few weeks but I have no idea what to do with it. Not sure how I would approach transitioning to another role really.
12+ years PHP and simple JavaScript programmer here. I loved programming and building websites.
Then I got into modern JavaScript with Reactjs, Nodejs, TypeScript, and other mess. Initially, I was excited because that's what everyone was and still is talking about and I love learning new things.
But it is too ugly in JavaScript land. People make fun of PHP but with PSR standards it is easy to enforce coding standards. In JavaScript land, everyone has their own standards, no easy way to enforce them, but most people don't follow their own standards. It is ugly spaghetti code mostly. Debugging tool is browser which makes it nearly impossible to troubleshoot when you are dealing with tons of minimized libraries. And even when you are dealing with simplest tasks JS developers start looking for libraries instead of just writing 5 line function.
I was ready to leave programming for management or other jobs but changed my mind and learning embedded systems, game dev, and some other cool techs. Hoping to transition to robotics or something else soon.
Interestingly, though, some languages get it right:
northrup@Topaz:~/Desktop$ perl -de1
Loading DB routines from perl5db.pl version 1.55
Editor support available.
Enter h or 'h h' for help, or 'man perldebug' for more help.
main::(-e:1): 1
DB<1> say 0.1 + 0.2
0.3
[…]
northrup@Topaz:~$ csi
CHICKEN
(c) 2008-2019, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.1.0 (rev 8e62f718)
linux-unix-gnu-x86-64 [ 64bit dload ptables ]
#;1> (+ 0.1 0.2)
0.3
[…]
northrup@Topaz:~$ sbcl
This is SBCL 1.5.8, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (+ 0.1 0.2)
0.3
That's a fair point about the Perl example, but Scheme and Common Lisp (including both Chicken and SBCL, last I checked) support (if not outright require) full numeric towers with rational number types, so these are indeed exact representations (unless you explicitly request binary floats for e.g. performance reasons) and not just rounding during printing.
There are lots of other examples of doing it "right" (using more suitable numeric types) over at https://0.30000000000000004.com/ (alongside a bunch of examples that, to your point, just round, or to the GP's point, just stick to binary floats).
Yeah, in CL the 0.1 is read syntax for a float (IEEE-754ish on most modern implementations.) If you want exactly 0.1, you’d have to say 1/10. The printer is probably cheating and rounding to the output you expect (I think Python 3 may do this now?)
Aside from financial applications, there’s very little reason to care about the trailing remainder.
> The printer is probably cheating and rounding to the output you expect
northrup@Topaz:~$ sbcl
This is SBCL 1.5.8, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (= (+ 0.1 0.2) 0.3)
T
* (= (- (+ 0.1 0.2) 0.3) 0)
T
> Aside from financial applications
"Financial applications" happen to be pretty common reasons for number crunching :)
northrup@Topaz:~$ sbcl
This is SBCL 1.5.8, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (- 0.3 3/10)
0.0
* (= (- 0.3 3/10) 0)
T
* (= (- 3/10 0.3) 0)
T
* (= 0.3 3/10)
NIL
So yeah, 0.3 and 3/10 are definitely distinct, but still apparently net out to exactly 0 nonetheless.
Scheme is the same. If you type a number with a dot in it, you'll get an "inexact" number, which is floating point. If you prefix it with #e, you'll get an exact representation of the entered number (so, e.g. #e0.1 gives you 1/10)
The output of inexact numbers is typically truncated. In CHICKEN, you can use flonum-print-precision to tweak that. In an example, straight from the manual:
Per my other comment, SBCL's defaults still cause (= (- (+ 0.1 0.2) 0.3) 0) → T. I guess they're technically floats (or at the very least not rationals) given that (= 0.3 3/10) → NIL.
I don't think it's so much a matter of getting it right as much as it is about preferring the performance gain and ease of use of hardware-accelerated constant-space floating-point numbers. At least, that was probably the case when programming in something like C/C++. I don't imagine there's much point to it in ruby or python for example, other than that floating-point is standard by now.
I second the nod to logic programming. I've been working on a board game engine in Prolog as a side project, and I'm having the most fun programming I've had in a very long time :)
I recommend starting with [0] to get a feel for what's possible. [1] is great when you have time to dive deeper. [2] is good motivation, and [3] will show you how to build a practical roles & permissions system.
Keep in mind that you don't have to build your app in 100% prolog to use prolog. There are likely implementations in your favorite language. For example, Rust[a] JavaScript[b], and Ruby[c].
When I first started learning to program. Every three months I switched languages/stacks, re-implemented a project in that language. Trying to learn the different approaches to development.
I also brought this on when I was a tech lead. Twice a month we would do code katas. Where we would do exercises together in a new language, or library. To continue learning, see if we could do things better.
I ended up in a similar place Functional(ocaml/ML) and multi platform (shared code for back end, mobile, web, and ops).
One of the problems I'm having right now, and is making me want to leave software. I can't find many roles that match that style. My brain hard locks when I try and go back to OOP at this point. I love programming, and working with the community. But right now I feel like I'm banging my head into a wall. Has any one else had this problem?
Of the many programming languages I have used over the last 20 years, there are several I prefer, several I would rather not use, but PHP and Javascript are the only two I refuse to ever touch again because they are so utterly unpleasant to write anything in.
It also makes my life as an end user miserable on the web on account of the gigantic gobs of program I have to download to make even simple websites work these days, when most could work just as well as a simple HTML page served from a server that didn't somehow manage to spin the fans on my powerful laptop just so it could show me some fancy font and I utterly resent the language, and the developers choice of it for forcing this on me.
Apart from all that, there's nothing wrong with Javascript at all.
I find it ok for it's intended original use, which is browser scripting. It's totally fine to write small JS scripts to make the pages a bit more interactive.
People got it wrong when they started writing huge applications in JS.
Just because a language is Turing complete, it doesn't mean it's fitted for everything.
It's like you did your job fine as a carpenter using carpenter's tools and you get a dentist job, but you insist on using carpenter's tools because you already know them.
Not OP, but I personally could not use JS, and would outright refuse to use, in production. It's fraught with headaches that seem trivial but drastically change control flow, == and === being my favourite example. Linters help, but it feels like a band-aid solution.
I've had good fun with JS in my own time (where else can you get a GLES window up in 3 lines of code?), and I've written my fair share of helper application that notify me of certain album releases. But I would never ship something using it (and in fact I generally switch to Dart if I get serious enough about a web project, another band-aid solution). It could be preference, or it could be the years of embedded programming expecting timely results with minimum overhead (make no mistake, a modern web browser is a hell of an overhead).
I had the same issue. Then I went back to the roots: Lisp
And learned Clojure.
You will feel like you know nothing.
You will feel handicapped.
You will be confused.
Then, one day, you will understand what simplicity means
and how Clojure's design embraces that more than in any other language I know.
By then you will have embraced the flying-by-your-pants-exploratory style of programming at the REPL.
And don't want to go back anymore.
+1 for Clojure making me love programming! You likely are burned out from corporate code because of the huge compile times, complex processes, and generally a ton a of typing. This will mostly go away with Clojure. What you will be left with is significantly smaller code bases, fun with metaprogramming, and instant feedback with no waiting for compilation.
I've been learning it for a couple of weeks. It is humbling as an experienced dev to find something quite straightforward (parens-whining aside, Clojure is a small & simple language), yet not have a clue how to approach problem-solving with it.
Use 4Clojure for practice. Talk about humbling! You’ll struggle to write a 20 line abomination and then see some wizard’s beautiful 2 liner that does the same thing. You might spend a long while grokking it, but when you do you’ve added one or more new tools to your Clojure problem solving repertoire.
Exactly my experience. I've dipped into 4Clojure (thanks for the suggestion), and also Exercism as the mentoring is handy. I really enjoy the way you can reach solutions that are pithy without being obscure or artificially terse.
It does take me a long time to get there though. It's kicking my arse to be honest. Which is fine, as it means I'm learning - far more enlightening than frustrating.
Me too. I was bored with 2 decades of C/C++/Java and didn’t like programming any more. Dabbled with Ruby, Python, Groovy and enjoyed them. Discovered Scheme, SICP, and Clojure and never looked back. Beat my head against not having my old problem solving paradigms, but it was fascinating rewiring my brain. It finally clicked and coding has been a joy ever since. The Clojure REPL rocks.
> You will feel handicapped. You will be confused.
For anyone who wants to learn Clojure (or any Lisp) from scratch, here's my advice:
Don't try to learn it by reading books. What I mean: don't try to mentally parse and analyze printed code written in Clojure. For uninitiated Clojure code may look like unreadable gibberish. If you try to understand Clojure code by merely staring at it, it may feel very exhausting.
Remember: Unlike most other languages where the code is "dead" until you compile it an run it, Clojure code is a "living thing," analyzing its "static" properties without evaluating that code makes little sense.
Get an editor/IDE that supports "structural editing." Learn basic structural editing commands - slurp, barf, transpose. Learn/set a keybinding that allows you to evaluate the expression at the cursor.
And then eval your expressions and sub-expressions. That would make it much easier to learn. And would bring joy to the experience.
I should've probably clarified: It is difficult to grok Clojure code only in the beginning - when you are new to the language. To many beginners, Clojure code at first may not look very intuitive. That is why I'm suggesting to learn it by "breathing it" - try changing it in an editor/IDE that supports structural editing and connected to a REPL - change an expression, eval it - see the results, expand, eval again, move onto the outer/inner level expression, eval, and so on. That way you quickly get the insight and learn how the language works. And it won't take too long to learn how to comfortably read and mentally parse "static" Clojure code.
After some time it becomes clear - Lisp is not harder to read. For some people, it's the other way around - going back to languages with C-like syntax may feel awkward.
I came here to say this, the REPL feedback loop is amazing, I think we can do more with LSP in Clojure with spec so I'm trying to build that out to attract people used to advanced type systems that would otherwise be put off
The problem is I don't have a good track record for completing projects so competitors or collaborators would be greatly appreciated
Yeah, then you won't be able to get a job anywhere and will puke at the sight of OOP code. Seriously, Clojure is by far my favourite language but with mouths to feed I had to put it down and get serious with JS, Python and Kotlin.
Clojure is still massively helpful to learn, even if it is not the primary language of use. It is guaranteed to make a better programmer from anyone who has never done Lisp or FP before. It is my go-to tool for prototyping - whenever I am not allowed to use Clojure, I still first write an initial prototype in it and then translate it to the target language. Even though that sounds counter-intuitive - I am far much faster compared to if I had to write directly in the target language.
I don't really get this. If you're working in the usual OOP environment (JS, Ruby, Python, Java) what use is it modelling your solution in a functional language based on immutable data structures? Isn't that like running around naked before putting on your straight-jacket ready for work?
First of all: every modern version of languages you mentioned has some basic FP primitives; second: most of the time, it's all about the logic (algorithm) and data transformations. Yes, sometimes, it feels weird, like trying to glue every single hair back onto your chin after you shaved your beard off. And of course, the approach has certain limitations - you can't use macros, you have to be careful with recursion and lazy evaluations, etc. And it only works for small problems, and I'm not talking about maintaining big projects that way.
I'm not the one you asked, but personally after I learned Clojure I completely joined the Rich Hickey cult and only sought out Clojure/ClojureScript jobs or jobs where I could decide what language to use myself. I'm now on my third one. It obviously limits your pool of available jobs significantly, but I try to keep up with which companies and organisations are using Clojure in my city and so far it hasn't been an issue at all.
And then you get so good at clojure that repl is "just another style" and it's not much different from Python in terms of effort or thought. After all, Python has a repl too, they just call it a shell.
I have gotten burned out of my personal clojure projects same as anything.
It's just a language people. Whether speaking Japanese or English, it's just a language. Yes culture is a part of it, but it doesn't imbue the speaker with some sort of superpower. Yes other languages are fun, but both get the job done. English has the word "love", Japanese has "yugen" but both peoples seem to get by just fine.
Well Clojure is a language designed to be evaluated form by form if for example I wanted to evaluate an if statement in PHP's "REPL" then working out where that statement begins and ends is annoying compared to just sending an if expression in Clojure
In PHP once a function is defined I can't redefine it and then call it again to iteratively build that function
Just because your language has a repl doesn't mean you can get a quick feedback loop from it, in fact the more compile time constructs you have like classes and interfaces the harder it is, particularly if they're sticky with dependencies everywhere
Bret Victor's work I think really illustrates how little respect and investigation we do into feedback loops
> After all, Python has a repl too, they just call it a shell.
No. Most non-lispy (non-homoiconic) languages do not have "true" REPLs (and that includes Python as well). At best they are just that - interactive shells. To understand the distinction, one has to give a sincere heartfelt attempt to use a Lisp. Having able to evaluate any expression and sub-expression without any preceding ceremony is extremely empowering. There's a massive difference in the workflow - any experienced Lisper can attest to that. The benefits of homoiconicity are incredibly underrated in modern programming. Perhaps you just haven't used Lisp for long enough to learn how to appreciate it.
> It's just a language people.
Yes, it is. There are many different ways to express something like "number 42" - using ordinary objects like sticks, or by counting numbers out loud, or by writing the amount using words, or by applying mathematical sigma notation. And Mathematics is just a language as well. And when it comes to expressing something far less trivial than natural numbers, we have not yet discovered|invented better ways.
That all been said - Lisp syntax is not without certain disadvantages. But in many cases - the benefits outweigh the cost. That is why Lisp as an idea is still relevant, even after over six decades. And until we figure out (discover?) a better way, the ideas behind Lisp still would be very useful.
The language itself is very stable. There were no breaking changes. You can pick up just any Clojure book (even old one), and probably 98% of it still be very relevant.
I became a manager. This didn't, in and of itself, make me rediscover the joy of programming. But it did free up the mental energy I needed to program outside of work, for fun.
As a 9-5 programmer, I often found myself too mentally exhausted to do any coding outside of work. This meant that over the years, programming became just a job, and nothing more.
But once I changed career tracks, I found that I had the energy to write code after work. It actually felt like taking a break. I went from "I need to get away from the computer and go talk to people" to "I need to get away from people and just write code". And when I was writing code on my own terms, without any project managers or other people telling me what to do, it became fun again.
I'm not necessarily saying you should move into management too. I'm lucky that I enjoy the people side of the job, unlike a lot of programmers. But I think that if you put yourself in the same situation as you were in when you first discovered the joy of programming, you'll be able to rediscover it.
I have been coding for almost a decade and I don't think I have come home any day and felt like, "oh, today I will code this!". Nope. I always leave work at work - coding, studying, learning about work. It's not really a discipline, or an attempt to keep work and life separate. I just don't feel like it.
After work it's just reading, films, walks, sports etc for me. I used to get bothered by it seeing other people code and learn tricks, tools, and paradigms at home. Thinking whether I am in the wrong profession, or I am doing it wrong. But now I have accepted it as this is who I am.
>I don't think I have come home any day and felt like, "oh, today I will code this!". Nope. I always leave work at work - coding, studying, learning about work. It's not really a discipline, or an attempt to keep work and life separate. I just don't feel like it.
I'm in the same boat. I've been coding for over 15 years, and since I've been doing it as a career, I can't bring myself to work on very much outside of work like I used to. I have a github full of projects that I used to work on but when I'm home I want to do something that I enjoy. I don't think I've made a significant commit to any of my projects in over a year. Almost makes me want to go back to being an electrician so I can find renewed passion for what used to be my hobby.
One of the criticisms of management path is that it just blocks your mind with anxieties, since you are dealing with lot of unknowns and things which you don't control ...
If you are truly able to switch off after work (as a manager) and still devote your energy on programming pursuits, then I guess you really have a good team and a really good job.
I would be interested to hear your experiences after you work with good number of teams which you inherit (not build them from scratch), and still feel the same way.
Wow, I'm have just started trying out the management track in my company, and your post is very motivating. As in, I thought I would lose out on the programming part, but if I end up with the same experience as you, I will make up for it by doing hobby projects again.
Have you ever considered what's making you not enjoy programming anymore? Journalling your day-to-day might help.
Here's one example that I found that really screws with people not enjoying programming. If you have a career, chances are you're going through rules/bullshit(ie. code standards, needlessly large codebases) made up by other programmers within your organization and that's making you not enjoy programming as much - in contrast to when you were younger and only needed to get things working.
On the bright side, there are ways to handle it. While I don't recommend going YOLO and willfully breaking all the rules or even quitting without a plan, I do recommend trying to find some other outlet/hobby that you enjoy after work hours.
Are you stuck in the rut of doing corporate cruft? I'm there, and it's unbearably boring. I'm finding inspiration in personal projects. Currently I'm investigating the effect of gerrymandering in the House elections. While I have strong personal political views, I'm doing this purely as a pet project. At the same time, I have to experiment with datasets and data sources outside of my day-to-day area of expertise. I don't have a deadline, but it's interesting. And I'm doing it in a Python, which is a new language for me.
Bottom line, it's a challenging problem, and a language challenge, so at the same time I'm expanding my skills.
I made games, didnt earn enough to keep it going, and went to corporate. Fortunately this job is a little lax on deadlines/schedules (though not so much on the cruft). Other than that, working on my games or related keeps me alive and looking forward. Spending time reading books helps a lot too.
I could really go on about this at length but my advice is:
- keep things simple. Avoid complexity at all costs.
- keep it fast - fast to compile, fast to run, fast to change
- if you don’t Like something, change it.
I stopped using frameworks, stopped using heavyweight runtimes, switched to a language that built and ran faster, and kicked out everything I didn’t like.
I can now focus on the actual problems I’m trying to solve instead of trying to work out how my problems fit into someone else’s idea of how to do things.
I went the opposite route and moved to a language that, while not the most performant, championed the idea of developer happiness (Ruby).
> if you don’t Like something, change it.
This is also super important, and a good point make. Don't ever choose a technology for the sake of looking good; choose something you enjoy working with.
yep! but it's not really about Go, it's about finding something that suits my groove. I don't for a moment think Go is the best language (I suspect Rust would be more my thing), but as an ex-Java dev, I'm tired of fighting the tools, and that's something you hear quite often with Rust.
So I compromised by trying Go, and my productivity has been really great. And productivity seems to me to be the thing that is most important about making me happy.
(actually I suspect most people would say they love productivity, but not everyone seems to know how to achieve it).
Burnout often occurs because who you imagine/want yourself to be is not the same person as how you actually identify yourself to be.
It can be the feeling of "I know I can do better than this, but I'm not doing better than this right now, so I'm frustrated with myself."
There is no quick easy fix. My only suggestion to you would be to: firstly, accept that this is crap situation to be in, secondly: that it is escapable, and thirdly: realize that to escape you have to return to your roots, and rebuild from there.
When you first discovered programming, it was fun and what you created only mattered you. You started here, so go back here. Do an ancient Advent of Code (https://adventofcode.com/), or the first few Euler Problems (https://projecteuler.net/). Do not share your solutions with anyone. The most important thing is that what you do is not important to anyone except yourself. This is your baseline.
I have. When I started using Rust for some real project.
I picked up a C++ codebase for a DCC app plug-in from around 2011 and started porting it to C++17.
At that time I had already started learning Rust. Three months into the project the DCC host app changed API which meant major refactoring on top of porting.
I decided: screw it – let’s rewrite it in Rust (RIIR).
It has been a most amazing experience.
I haven’t felt like this since I was 14 and started learning C and later (Turbo) C++, when I was 16.
The language and community are amazing. Lots of new material that is outside of my comfort zone. Steep learning curve but with the reward of this warm feeling of learning something new almost daily.
I'm about 10 years into my software development career. I have felt exactly what you are describing once or twice. From time to time I feel myself become somewhat tired of programming and tend to move onto other avenues of running a SAAS product, for example, marketing and sales.
I found that the core reason I temporarily lost my love for programming (or nearly lost it on multiple occasions) was because I was coding all the time and was burning myself out.
The monotony of working as a software developer during the day and then coming home to work during the night on my side projects[1] had left me feeling down when my tasks in work or my projects at home didn't work out the way I had planned. On the flipside, when I did things which I considered to be an achievement at work or at home - I felt better in both environments. Almost like a surge of energy. Work/life balance is, of course, a two sided coin and they both have implications on the other.
I think one really needs to find other creative pursuits besides those which they are inclined to practice on a daily basis. It's fantastic to hone your skills in a particular field however I have personally felt that switching off from time to time and dabbing in completely unrelated work would allow me to recharge. In fact, it would help me think of new ideas as my mind had time to process my thoughts and the work I had completed.
When I 'burnt out' in the past I needed several weeks to rest, read, explore my city & countryside, cook my favourite foods, watch my favourite shows and just take care of me.
In order to avoid burn out, I decided to pick three hobbies: one to make me money, one to keep me in shape, and one to keep me creative. I'm sure I read that somewhere! Some of us do this by default, and there is a lot more to life than those three hobbies.. all I know is it has helped me to pace myself[2], to enjoy life a lot more and to achieve my goals at the same time :)
A lot of good advice here, adding my recipe for avoiding burnout (~15yrs into my career):
Delineate between not enjoying your job vs. not enjoying your profession. Sometimes getting a new job in a better work environment and especially with a better manager helps immensely.
Get a new job that is adjacent to software, like technical program management, sales engineer, developer evangelism, etc. Here you can still leverage your extensive programming experience but not have to code. For me - I quickly re-discovered my love for programming.
Treat your employer like your customer. This lets you side-step all the petty office politics, the rat race for the next promotion, etc. which are big contributors to stress-related burnout. Your customer is paying a fair market value for your services - the day that does not hold true, you part ways. No hard feelings.
I got into creative coding and procedural generation using things like Processing[1], StructureSynth[2], ContextFreeArt[3], libcinder[4], but also just plain C programming to do similar kinds of things, and there are some inpiring subreddits, r/creativecoding r/generative r/proceduralgeneration
I think the major difference with this kind of programming is that unlike normal programming, you don't necessarily have a very clear idea at all what your program's output will even look like until after you try it. So there's more of a feeling of "discovery" rather than "invention" and much less of a concrete notion of "correct" and "incorrect" output and it's a pretty different feeling that more "normal" programming.
Stop programming. Do something entirely different (painting, through hike, buy a one way ticket and wander, landscaping, sculpture, etc.). Let the well refill. If you're not financially able to take such a break, start saving like mad. Put a stake in the sand (say two years hence) when you will stop to recover.
For me, the joy of programming is in solving (algorithmic) problems, not the design of 'enterprise applications'. During my day job the architecture is way more important than cranking out the best performing algorithm all the time. And I enjoy the architecture part to a large extend luckily, but it has burned me out in the past.
So for me, what got me passionate about it again was picking up a new language and doing things like projecteuler or leetcode etc. Just trying to solve algorithmic problems with a new language, playing around, learning, improving the code.
Every now and then I need to repeat this cycle. :)
If you really do the exercises (an hour here and an hour there), you can feel you brain getting wrapped around many core notions in very illuminating ways.
I've been going through SICP for a year and a half now on and off. At this point I don't feel I've been getting back all the effort I put in it.
I think it's mostly recommended by people who didn't do all the exercises, or casually browsed through it and all they were left with was the fact that you can write a programming book without mentioning assignments until halfway through or that it's more easy to write a scheme interpreter in scheme than other languages.
But the book is really dense, and you won't be left with much after trying to debug your hundreds line script meant to solve one problem.
If you’re interested in the Structure and Interpretation of Computer Programs book, I ported the first portion to HTML (with a built-in Scheme interpreter) here: http://jaredkrinke.github.io/learn-scheme/
I find I get burned out by commercial code. So many hands have touched it, millions of lines, scant docs, hard to make sense of it, but ... deadlines, get this task done and that.
Create a simple program outside of work and connect with the joy again!
I am having fun writing a simple nodejs app which is using AWS service. Nothing groundbreaking but its fun to learn and tinker with. I have no expectation of getting good at AWS or NodeJS, just want to build something and get it working.
Create a simple program outside of work and connect with the joy again!
I found the opposite was useful. My day job was writing quite trivial code (crud apps, forms, etc) so I started writing far more complex apps in my spare time. Things that were truly challenging. It turns out they're a lot of fun to build.
My day job is fixing what should be trivial code that is ridiculously over complicated for what it is doing. Most apps are just a variation on CRUD, yet people manage to make this ridiculously complex.
There are two kinds of difficult I find. Difficult and rewarding (coming up with an elegant algorithm to solve a problem). Difficult but unrewarding. It doesn't take brainpower to solve these, just knowledge of lots of inconsistencies and a lot of trial end error. Interacting with Saleforce API and a lot of JavaScript / Browser work seems to fall into this category.
I can see that being true too. The parallel is your challenging code and my simple code have is that they are solo dev projects (presumably!) with little legacy, and you get to choose the direction you take them in.
I'd say write manageable programs.
The uglier the codebase gets, the more I hate coding it.
If the codebase is well-thought and easily extendable, coding is mostly fun and you get pleasure out of beautiful execution.
This got me thinking. I find that being repeatedly told not to clean up a system burns me out. To the extent that our programming is creative and enjoyable in its creativity, one must feel some sort of pride in the result in order to have any interest in its continuation. If you are being told to not clean things up or leave things in a messy state, you are left devoid of this sense of pride and joy in your work.
Best case, you can find pride and joy in something about your programming other than the technical excellence. However, that depends on you personally caring about the purpose of your code's existence.
Of course, left to their own devices, a bunch of engineers could be very happy and ship nothing useful. So you have to impose some sort of balance in a business environment. However, it's an interesting management problem to allow people enough time and autonomy to be proud of their work, while still accomplishing what needs doing. Ideally, with happy engineers, more gets done, and it pays off.
Yeah, this applies to any profession. People not only burnout because they have too much to do, but because of the stress of not being able to do their work well. It's a tough problem.
I'm in a bit of a reverse situation. I left programming some 12 yrs and want to get back into it. But I find it so hard with all the commandline installs, config files etc. The barrier to just getting to "hello world" seems so high now. Pasting my recent ask HN here in case I have better luck:
What is the easiest way to launch a simple PHP website these days?
-A simple CRUD web app
-No new sytax to learn (just good ol' PHP)
-Simple flexible front end library (I have used Materialize CSS, is that the best?)
-Any easy way to make the MySQL pieces easier to manage? Any boilerplates?
-Any end to end integrated development environment? I have codeanywhere subscription and inmotion hosting. Is that good?
Essentially I have decent experience with PHP/MySQL from past and want to launch a simple CRUD website using as much off-the-shelf pieces as possible. Looking for the easiest path to get there.
It would be gravy on top of some day I can wrap it into a mobile app (for location, camera etc.)
Does it have to be PHP? No offence but you’d get so much more from learning Python and the barrier to entry really isn’t that high.
The hardest hurdle initially is to set up a “virtual environment” which means you have a project by project collection of all the packages you need instead of installing everything globally.
Setting up virtual environments used to be a pain. Today it’s so easy:
1. Make sure you have Python 3.8 installed. There’s installers for Mac and Win.
2. Create a folder for your new project.
2. Inside that folder, use your console or terminal to write: python3 -m venv p_env
3. You now have a virtual env, all your stuff will be stored in that p_env folder.
4. Activate it with another command: source p_env/bin/activate
5. It’s now activated and you can use “pip” to install packages like Django a great web framework.
By the way go check out Django and go through the tutorial. It’s very fun and will get you going with a CRUD in no time.
It need not be PHP. Just that I'm most familiar with PHP and ASP.net from back in the day. I'm confident that I can pick up most languages. I will look into Python and Django. But honestly the setup steps already scare me a bit :)
ASP.Net has moved on a bit and can now be hosted on Linux or Mac. ASP.Net Core 3.1, which will become the all-new integrated ASP.Net 5 at the end of the year, offers a much more mature developer experience without all the MS lock-in (MS SQL Server / Windows IIS etc.). The free version of Visual Basic actually runs pretty well on Mac OS X.
Go for it! Forget about setting a DB at first. Django will default to a “pseudo database as a single file” called SQLite and for all intents and purpose it’ll function as if it was MySQL or Postgres.
I was in the exact same position -- the ecosystem looks intimidating these days, but fortunately PHP is pretty much still PHP. I started back in by getting a handle on Composer[0], which is the only new necessity, and if you have any *nix experience is just a basic package manager (so you don't have to worry about checking for updates and managing individual dependency files like the old days).
Composer also provides the benefit of a lot of neat packages that can help accomplish a lot of the heavy lifting, depending on your needs. For my purposes, the Slim Framework[1] was perfect. Beyond that, PHP still has PDO, so I wrote a simple class to manage my common CRUD activities. I haven't bought into the npm-gulp-JS-babel hamster wheel nonsense for the front-end. I still download the odd JS library and FTP upload my files.
Tying it back to the OP, I really rediscovered the joy of programming by ignoring all the over-engineered nonsense that's taken over (particularly in web dev). I stopped feeling like I'm behind if I don't spend a day learning about a process that might save me 20 minutes but will be deprecated in a month and obsolete in a year. I went back to just writing the code that does what I need it to do.
> I have decent experience with PHP/MySQL from past
Let's be honest: you don't have any experience with php or mysql anymore. 12 years ago was the era of php 5 with some remnants of 4. Php 7 and the ecosystem are a lot better nowadays (composer, Symfony etc.). For database people tend to use Postgres when they can but even MySQL added lot of good things with JSON, CTE, window functions.
You may want to start learning from scratch.
"Hello world" is still those letters in a .php file uploaded to a host tho.
I can't think of anything that doesn't have a steep learning curve, aside from just not using any frameworks and writing PHP code. If you're building something solo and it's not too complicated, that's a decent option if you don't want to spend time learning things that won't get you to hello world. But, depending on what you're doing, something like WordPress might do what you want out of the box.
FWIW and IMO Java and .Net has gone in the opposite direction of many others and I find myself reaching for them now (I used to prefer PHP, later PHP/Symfony, smaller PHP frameworks and then Python with Flask but the last 5 years Java and .Net has become so simple and fast (in dev, prod has been fast for a long time) that I see no reason to go with anything else.
I started with something that's completely unrelated to my professional work and to my other side projects: home computer emulator programming.
I moved from C++ to the much simpler C which I started to enjoy more because it's not putting such a "mental barrier" between my brain and the problem to solve (another option would've been to use an entirely different programming language you're currently interested in but can't use "at work").
Basically: have one or several fallback projects which are completely different from your usual work, without any self-imposed deadlines or long term planning to go back to when the other work becomes boring or overwhelming, just having fun is the main point, and part of the fun is going back to the core of what makes programming actually fun: Just whipping out code in a way that "feels right" to you, and seeing things actually happen, free from outside opinions or priorities.
From time to time (usually over the Christmas holidays) I take a deep dive into this project, but otherwise it's just a few hours a week at most, usually with months-long pauses inbetween.
PS: it took me a few months to "detox" my brain from the "professional software development process" that has become the norm in the "industry" ("agile" processes, software development patterns, estimates, tickets and all that crap). Those had been deeply ingrained into my brain in the last decades, but it's important to realize that all these things are, in fact, turning programming into a chore where burnout is ineviatable.
We got into it because we loved it then it became our job and what started as something we do for fun became something we do to survive. We no longer have a lot of freedom what we want to program and we are required to code for objectives that doesn't interest us.
On top of that, it becomes something that identifies us and more or less the only tool we have at hand to prove we are successful.
Many start dreaming how can they change the world with this tool and invent the next big thing.
We start attempting to hit jackpots by creating one project after the other and failing miserably in all.
By late 20s mid 30s we get burnt out from failure and many move to management.
The ones that stick are the ones that program for no reason other than they enjoy it and are content with that. They aren't trying to change the world, become super rich etc. Sometimes they do by mere luck but it wasn't their intention.
My suggestion here is to tinker. For example, when was the last time you benchmarked a string comparison function and found out exactly why it bottlenecks down to the cpu instructions, instruction ordering, barriers, caching etc ? It's fun and can suck you in for days and a great learning experience. The example here is specific, but the gist of it is not. I hope it helps you.
For me, I took 2 years off of programming entirely and did something completely unrelated (started a monthly subscription box, so mostly marketing/sales/procurement).
I was completely burned out and couldn't stand to code even side projects when I started the hiatus. When I was ready and got back into it again, the passion was 100% back. Still going strong 3 years since.
I used Cratejoy to handle the e-commerce backend, so the extent of it was some minor HTML/CSS work. There's existing solutions for Shopify that do the same as well, so no programming needed.
Later on (still running 5 years later), when I got back into coding again, I got rid of Cratejoy and wrote the backend from scratch in Ruby.
Probably 20 years ago, you were not excited by programming... You were excited by what you can achieve with it... Get back to that realisation again by coding something that's impacting someone... For example, Take google spreadsheet and generate inference from some public data, further more do some automation around it and get more stuff.. See if you can help people at this time of crisis.. Get back to the excitement of achieving...
If it is a consistent feeling then may be you are ripe for change. However, if it comes in phases, then following works for me in exact order. Frankly, following is more for "developer's block" but may be that's what you are going through.
1. Try something different, new. However, it should not be complex, at least not to start with.
1. If that doesn't hooks you, pick a small trivial, meaningless utility to write in whatever framework you are comfortable with. It is important not to overshoot - really just pick a "meaningless" and simple task.
1. If that doesn't work, pick some small utility from a blog/video where full code is available (many examples here - https://news.ycombinator.com/item?id=16591918). Write whole code again, copying line by line. As you start getting involved, stop copying and start thinking how you would write the next function, or what optimization you'd do for current function, etc.
1. If that also doesn't work, take a break. Don't think about programming at all in that break, that's important.
1. If that doesn't work either, start looking into other roles/domains and what might suit your background and strengths. As I mentioned earlier, may be you are ready for the change :)
Try to connect with the creative side of self, try to connect with the internal kid that used to love programming, try to connect with the 'creator' part of self. And at the beginning just do it for yourself, from pure curiosity, to sparkle the joy once again. Don't focus on programming but what would you like to create and using programming as a tool.
What works for me to re-connect with the technology, when once again being close or after to burn-out or in a bad cycle at work is to slow down and 'play' with the technology, and on my own pace.
Years ago I worked in gamedev, so when challenging mental times hit, I sometimes tend to come back and just 'play' a bit with graphics, visualisations, interactive environments, simulations. I am fully aware that I am not going to compare with professional game engines, but it's just to enjoy the creative process, to freely play with ideas; to no care about lines of code / modules that won't pass code review, etc. hence also not being too much restricted by any frameworks if possible. Let the ideas flow once again and let the mind create.
As a side note, not so long ago, I also bought Raspberry Pi with a pretty nice, affordable kit of sensors. Electronics is fun, when apart from creating stuff virtually, you can create it 'outside'. You can touch it, you can hear it (and even can sometimes smell it when burns) and can control stuff writing own simple scripts. Installing Jupyter Hub on Raspberry Pi and playing interactively with sensors and collected data in Python and is just another fun moment, opening further possibilities to explore.
Totally agree! I'm in a similar position, albeit not 20 years, but 3-4 years. I have realized that I have to connect with creative side of myself and do things for the enjoyment of them.
I'd like to plug the Recurse Center (recurse.com) - it's a "writer's retreat for programmers" and helped me find a community of people who really enjoy programming. I attended 7 years ago and it's still a part of my daily life.
I also would plug !!Con (bangbangcon.com) and StarCon (starcon.io) as conferences specifically about the joy and excitement of computing. Those might be a good source of inspiration for you. (Full disclosure: I help organize !!Con).
I think one of the important things is to find people who do joyful things with computers and spend time with them, or at least follow their work.
I wonder if it’s complexity that makes it less fun? I have been programming for 38 years and went through a similar feeling. After the lockdown I picked up RISCOS and BBC basic, and learned the Teletext display standard (mode 7) in BBC basic. The feeling of being able to quickly understand a simple system and make stuff is great fun. Learning Teletext layout is only a few pages of reading and the standard itself for mode 7 fits on one A4 sheet. RISCOS is another simple thing to learn and you can access every aspect of the OS through BBC basic calls. I spent a few weeks doing this and then returned to unity c# work. I started with the Pico build for raspberry pi and thus - no mouse and using the text editor to write BBC basic. When I returned to using modern tools I had a new found appreciation of the power at my fingertips and got my mojo back. Having a break and doing something completely different for a while worked for me.
I went through it. Stopped coding in C#, uninstalled Windows, installed Linux and started learning everything all over again, starting with web dev in Go. The joy of exploring a new environment and language really helped. Still hasn't faded.
I'd also second therapy. Your loss of enjoyment may be a sign of wider issues. At least get it checked out. And you're in the prime age for your "mid-life crisis", which is a real thing that people really go through. Mine was a bastard. Therapy helped.
I’d say give Racket a go. It is quite easy to pick up and very rewarding to program in. I feel that I got some of the excitement back while learning racket and toy-coding the material i was learning. DrRacket is weird at first, it a very idiosyncratic IDE but i grew to like quite a bit as well as the LISP parantheses. I find them quite visually pleasing after a while and the IDE makes it very friendly to code in. If interested I could expand on details.
I'm in a similar position - to the extent of largely giving up work.
I may differ in that I'm not really determined to rediscover programming. I have many interests, don't need or want much cash and am quite happy to cobble together income from other sources. But I am curious to probe the extent and permanence of the loss. Learning something new is my approach - Clojure, for the combination of lispy paradigm challenge with practicality (it suits a couple of projects I have in mind). So far I'm enjoying it more than I expected. It's refreshing.
I don't know what the results will be in my case. But learning/discovery is so close to the heart of what attracted many of us to programming, I suggest reconnecting with it as one approach.
I did a brief stint as an architect and realised after about 3 months of doing that, that the things that had started to annoy or bore me about programming were all quite trivial things and I should just get over myself. Since then I've been programming again for about 2 years and quite enjoying myself.
So basically, take a break from programming and do something else for a bit, and don't sweat the little things that annoy you day-to-day -- try to appreciate instead all the creative freedom and chances you get to really test your intellect.
My current problem is that I write Javascript/TypeScript at work and have come to absolutely loathe every aspect of it because I've been working with much, much better languages at home for hobby projects (Elm, PureScript, stuff like that).
While I have not really lost the love for programming, I've discovered the sheer amount of work one has to do in JS/TS for the smallest payoff. Sure, the languages I'm using for fun might require a lot of study before they can be used effectively (PureScript especially, since it's practically Haskell), the productivity gained is phenomenal.
At work now, I feel like I've got the pedal to the metal but the wheels are spinning the the movement forward is measured in inches per hour, or sometimes per day.
But that's just what every frontend dev job is going to be. There are a few here and there using something better than JS/TS, but not in my area, and they are so few and far between that I probably cannot compete with their other candidates (who, for example, likely have a degree while I do not). So instead of burning out on programming, I've burnt out on the stagnation of the whole market. I'm certainly not the first and of course I will not be the last, but it's really killed my motivation to go further in my career despite still enjoying what I actually do.
I don't want to be a manager, I don't want to run a business, I want to be a programmer.
My main interest is FRP - especially Cycle.js (typescript) RxJS, and GunDB - a js graph database. Also Idris for a couple of years from now. To me these are the tools worth to learn and use but can't find any job with them. :(
Ha, similar. Try encouraging your team to adopt the likes of fp-ts and newtype-ts piecemeal, it's certainly not as good as the likes of PureScript but it can at least enable you to utilise composition, Option et al, etc.
I'm only at around 13 years of professional programming, but I went through a period of 4-5 years where I stopped enjoying it (actually, I hated it).
What resolved it for me was pretty simple in the end: I joined a company where I really believe in the mission, and I'm surrounded by like-minded people. This has given me a great amount of motivation and reminded me that programming is a superpower. I was simply lost on where to apply this superpower.
Solving important (to me) problems has re-ignited my love of programming, and now even writing yet another piece of CRUD is fun because I believe it will make a difference in the world. I'm looking beyond just the code I'm writing down and thinking about how it helps our users, effective communication, how growth will be affected, how malleable it is, how quickly I can achieve the goal, and so on.
Another thing that helped me was researching other careers. I found a couple of things I think I would get a great deal of satisfaction from. I felt very trapped in a career I hated, and looking at another 30+ years of this was like a dark cloud over me. Giving myself an escape route gave me a lot of clarity and lifted that cloud. I can walk away at any time, if I want to.
> Another thing that helped me was researching other careers. I found a couple of things I think I would get a great deal of satisfaction from. I felt very trapped in a career I hated, and looking at another 30+ years of this was like a dark cloud over me.
I sometimes wish I had gone to school, but for something other than CS. I got into software development with no career at all, there arent a ton of other interesting fields open to uneducated people. If I had gone to school for some other subject I was interested in, i could still have the option of a well-padi software career, but also in something else that fascinates me, as well as opening up a new class of "hybrid jobs" using programming in specialized domains
I am in the same position. I also wish I'd gone to university, taken my education seriously, and done something other than CS (all easy to say in retrospect). There's still time :)
There are plenty of careers out there that are open to smart but unqualified people though. Once I looked around I realised my options aren't so bad (and some of the options I found may tempt me yet).
there are a number of video games by ZachTronics in which you program in assembly language for fictional computer architectures in a sci-fi settings. “Shenzhen I/O” and “Exapunks” are both fun.
They really manage to strip it off to the problem-solving and optimization, with a clearly defined scope. No architecture, very small design choices, no compatibility, build errors, package versions, Stackoverflow, compiler issues, "am-i-solving-the-right-problem" etc.
I'm still in it after 10 years... self-taught at 12, did some "proggies" for AOL--mostly did programming for fun, eventually at 18, I quit, and would not return until I had to.. at 26. I just wasn't interested in it. Wanted nothing to do with computers... went off to college, studied psychology, lived in another country, taught English, came back home... no one was hiring, except a company that needed the skills I learned when I was 12.
Although he was a tyrant boss that I couldn't stand, he taught me what I would need to know to go on and stay focused on the "task at hand" when it came to programming. I started getting into web design and development at the time as well, and made the switch. Been at it ever since.
I used to be a gamer in high school. I'd skip school to stay home and play Asheron's Call. I was so addicted to the game that I was the first to max out on the server of Harvestgain. Had a whole bunch of people come watch the fireworks. It was awesome. Anyways, it was a year after high school and I had been playing that game for 5 years, before realizing that I was just "wasting my life away" playing video games, which is what escalated a push for me to go to college and kind of taught me a valuable lesson: what if I could monetize something I enjoy doing? Programming = being creative, coming up with new ideas, making them a reality, etc.
I work for the media, I freelance for a few companies, started a blog, and started my own business ( https://notetoservices.com ), developing web apps for a variety of different purposes. So I tend to just keep myself busy, coming up with new ideas, and a lot of ideas stem off of other ideas, some free, some monetized. Keeps things... joyful.
My journey to rediscovery the joy of programming started at a local FreeCodeCamp meetup group. I simply showed up every meeting and got to know some of the regular students. I helped them with problems that were simple for me, but explaining concepts creatively to them was a very interesting experience.
The students needed a project to show on their resume so I got together with them to have weekly sprints like a mock engineering team. I taught them good coding practice and slowly built up an engineering team of student engineers during my free time. It helped me rediscover engineering practices and finding open source tools that mirror what I use at work is really eye opening and made me a stronger engineer at work. I understand things with a greater depth.
I really enjoy teaching and have been thinking of doing something similar for a while. The biggest hurdle for me is carving out some of my “decompression” time on weekends...
I feel very similar so probably don't have great advice, but as someone else mentioned it depends on your particular scenario. For me I have a day job at a company then my own company on the side I do a few hours of work a week for too. After dealing with all that work (much of it involves programming or related efforts), I have nearly zero energy to think about programming outside of that.
I used to have various side projects and programming passions but as soon as I think about them now my mind just numbs out. All the creative programming energy is going into other things.
So I kinda gave up on trying to hobby program or think of it as something I like to do but as work, and when not working try to do anything that is not involved with it basically. I still wonder if sometimes I could find another small business or job that wouldn't involve programming so I could do it as a hobby again but the money is too good to pass up so not sure what I'll end up doing. I feel like if I could retire I'd soon go back to hobby projects and enjoy it more again. Who knows.
My sentiments, precisely, and I’ve found the explanation at least for myself. Picking up a programming project sporadically involves re-learning for rapid proficiency — like context switching but from a hard disk.
Programming in our youth required one language/framework such as C/UNIX or even Visual BASIC. In contrast, to develop something useful today, you need to learn a different language or framework for the UI, services, DB, security, deployment, and others. Each offers its own universe of packages, tools, procedures for debugging, troubleshooting, and building.
One can certainly persevere and complete a full-stack application with the aid of StackOverflow, Dash, and Google searches, but there is no pleasure in it. The drudgery replaces any sense of gathering speed you feel when you’re proficient and rushing with satisfaction toward your next stopping point — before you realize it’s 5:00am.
My guess is that you keep returning to Hacker News in search of that one-stop language which will offer a hobbyist the old-fashioned combo of proficiency and completeness.
I feel like I got stuck in a rut a few years ago, was working in an obscure language, job was well paid but pretty dull, then I got made redundant and to carry on working in the same field would likely mean a move to another country, and I really didn't want to.
So, I had a Mac and iPhone, some hobby projects I'd dabbled in, and just went all out to learn Macos and iOS development, starting with Objective-c and later swift. I know many here will balk at MacOs, and it is a bit niche, but iOS was really interesting and led to a new job. I think iOS can still offer some challenges that older programmers might enjoy, there's still room for optimising and tweaking perfomance, memory and file size, and it's fun to find out how powerful modern mobiles really are. It's really easy to get started, and you can quickly get to building something really powerful, play around with the AR tools, look at the machine learning. There's good frameworks to get started and powerful stuff like using Metal once you feel like really tweaking things.
I similarly have loved programming ever since I was a teenager, and had grown super-cynical about the whole enterprise until about a year ago, and now am 100% back in love. The biggest reason for this is shifting my focus from "programming as a job" to "programming as creative act", somewhat a la our gracious hosts article:
In order to actually make that shift I personally was recommended the book "The Artist's Way" by Julia Cameron. If you are anything like me you may experience an intense aversion to something so "artsy", and I 100% understand. BUT I decided that since following that instinct had led me to what I thought was a dreary dead end of bad code forever, I should at least give it a chance, and it was indeed as effective as promised.
The work environment may have burned you out, or the years may have ground away the initial joy of learning. Either way, my suggestion is the same.
Look around for a charity that you value, and that you think could make good use of your skills. Local charities often lack people with programming skills, so your contribution might be very valuable to them.
If things go well, you might revisit the old thrill of overcoming unfamiliar challenges. You may take delight in the fact that you are making a difference to something important that goes well beyond you and what you thought was your career. Almost certainly, you'll also make some new friends who can teach you a thing or two, perhaps about things you've never pondered before.
Keep an eye out for someone you can teach. That way, your skills will be magnified, and you may find yourself looking forward to each new day in a way you haven't in a long time.
Find a project or loosely related group of projects that excites you but requires some programming to execute: for me it has recently been pinball machines, automated midi controlled instruments, and modular music systhesis with vcvrack.
Another example group might be drones, autopilot systems, and software defined radio.
Yeah, after 35 years in the profession, I've stayed (mostly) entertained by delving into nontraditional problem spaces that require me to learn about new subjects more than programming tools.
After my first job of coding w/ databases, I wandered into discrete event modeling for the FAA, building the graphical display of a R&D air traffic control simulation. Next, I built a distributed Unix-based server framework to visualize tactical entities on multilayer map products for combat C^3 simulations. That led to fielding a very large database on a massive parallel supercomputer for gov't intelligence sifting. Then I helped others to use of supercomputers in academia, and finally, I ended up in biomedical image analysis to assess drug development, now involving (deep) machine learning.
So rather than learn how to do the same old thing but switch languages periodically, I opted to learn new problem spaces or employ novel computational models. I can't say such a wandering path was ideal, but here I am still coding in my fourth decade.
Frankly though, I think my next transition is approaching. Maybe it'll be music synthesis or speech recognition or adaptive computer security. It's a big world out there.
I lost my enjoyment for programming. I wrote very little code for about 5 years after burning out. One of my friends wanted to do a joint coding project and he suggested Haskell, so I solved one or two hundred project Euler problems in Haskell. I never got good at Haskell, but I really do enjoy writing smaller projects (less than 5,000 lines of code) in Haskell.
Haskell inspired me to read two fairly easy books on Category Theory. I really enjoyed that also.
I still don't write a lot of code. Every few months, there will be a problem at work that needs my help and then I write the equivalent of 3000 lines of C++. Or, there will be a math problem that I want to solve on the computer. I really enjoy writing those shorter, self-contained programs.
Take a short break if you can.
Use it to meditate.
Try to understand what makes programming unpleasant for you. Is it the language? Is it the framework which you are using? Is it the tools? Is it a particular ecosystem? It's about what you are tasked to do? It's about how the development process at your organization is set up?
Try to change what bothers you. Try to identify what you would like and make a goal reaching that point.
If you end up discovering that you don't like anything about programming, so be it. Maybe it's time for a caree change.
In my previous job I was a game developer and I began to dislike what I did. Now I am a web developer and I enjoy it.
I can't tell you why you don't enjoy programming anymore, perhaps you're more interested in other things in your life than solving problems? (because that is what programming is, at least in my experience, languages are "just added flavor")
I've had times when I don't feel that I'm enjoying programming, followed by times when I'm really into it, there was this talk called "The Art of Code" that might interest you, the presenter Dylan Beattie shows what I now think is what makes programming interesting, it's about doing things, the programming is the how, not the what
For me, the main difference between programming being joy or misery is deadlines. When I'm tinkering at home solving some problem without any timelines, I'm super happy. When I'm solving a problem at work that has relatively flexible timelines (which is rarely the case lately), I'm very much enjoying myself. But when there is timeline attached coupled with "where are we with this" every alternate day, it takes all the fun out of it. I do understand that this is real world and this is how we operate etc etc but that is how it is for me.
I did start a project for a friend recently and working on a fresh codebase makes it a lot nicer (then I had do import messy data from Excel and it was back to disliking it again).
Around 2011 I started a fresh system for my work and learned Django along the way. That really encouraged me at the time. Everything seemed so well thought through regarding Django and it ramped up my productivity a lot, despite being a new framework and a new language to me.
I think the creative part, designing and coming up with something new helps. Most of jobs hoever are just fixing other peoples crappy code.
I sort of did, in the past year or so, in two ways.
The first thing is that as a hobby I worked with Go, just on the occasional friday project; it felt quite liberating to work in a fairly low-level, yet productive language, working on projects where quality is not an issue. I did random projects and Advent of Code projects.
The other one was Pico-8, a virtual console with a built-in editing environment. The language is LUA I believe, but since you work inside of the constrained environment, which has a screen of only 128x128 pixels, it's a very low-resolution font with only just over 30 columns wide. The code you write can be hacky and use tons of one- or two-lettered variables, it doesn't really matter; it's your code, nobody will ever collaborate on it, and with the constraints in place you can't ever write more code than you can keep in your head at one time. In theory anyway, I mean if you get ambitious you'll end up minifying your own code to make it all fit.
But anyway I digress; I managed to get a new job where I can work with Go a lot, which is giving me a fresh lease on the developer job. It's also a job where I'm the sole developer (for now), meaning I don't have to fight any political or ego-driven fights (or, much less) to do what I think is right (and in a lot of cases I just have to prove myself I'm right or wrong).
Learn something new. Learning new things is the only way to be happy. This is true on a neurophysiological level - the hippocampi of depressed people are shrunk. Happiness, positive emotions and learning and memory all take place in your hippocampus.
Learning and living are really the same thing. Both are just the formation of new synapses in your brain.
Practically speaking, change things up! Maybe find a new job, start a new personal project on something you've never worked on before. Take some time off if necessary and possible. But be sure to fill your time off with as many new experiences as possible.
Also, _passion is a skill_. Sometimes it comes naturally, but it can be cultivated, too. This is called the "growth mindset" (See Carol Dweck's book, "Mindset"). The growth mindset has been extensively studied over the past 3 decades, but only as it relates to intelligence. Now, psychologists are discovering that it applies to passion as well as intelligence[1].
So what does a growth mindset entail? You can only grow (in passion, intelligence, etc.) if you believe you can grow. So 1) believe that you can cultivate a passion in your career and 2) learn new things.
I had a pretty severe burnout 2 years ago. In my personal experience, the above is how I rediscovered a love for computers.
I think you have to find what interests you. Think back to the times you were most excited—what was different then?
Personally, when it comes to putting code on the screen I am motivated mostly by two things:
1. I am excited to put a puzzle together. The same thing that makes me interested in finishing a basic puzzle like a sudoku applies to writing code. I want to see my end result work, and putting all the steps together in my code is enough to keep me up late.
2. I am oddly excited about learning and applying best practices. Often I initially solve a problem by mimicking existing patterns. Then I will spend hours pouring over man pages and standard library documentation in order to figure out the best way to do something.
For me, everything else feeds into those two basic motivations. In my career I get to apply those concepts at a larger scale. I'm finding that my motivations extend to domains other than code, both in my career and in my personal life.
I encourage you to reflect and consider the moments when you felt the most joy and the moments when you felt the least joy, and what was different between them.
I dropped programming after my first real job. I used to program from a young age (Basic, pascal, C, ASM) then played with GNU/Linux and BSD then on networks with Cisco and Juniper to setup some BGP route (internship) all of that was a lot of fun I loved building mini video games or my own operating system. But once I started to work and some guy who did not know programming was asking me to do some not fun code about accounting and I had to work with other programmers I realized I loved to play but not to work. I then moved to the business side as I liked learning new things and I got to tell programmers what to build without having to be bored. But consulting became boring too. It took me a while but I found happiness in entrepreneurship and started to code a little again while doing business or non profits. I think building your own thing is a lot of fun. At this point I would maybe recommend you to take a break and not code for a little while to see where your true north is. Good luck!
Jerry Weinberg has a chapter on burnout in one of his books [0]. He refers to the idea of 'the oxygen mask', making sure you've taken care of yourself so you have resources from which to give. He talks about how having a long list of 'shoulds' can wear you down, and how competence can lead to collecting more responsibilities than you can manage.
He then places burnout at the foreign element stage of the Satir Change Model (see, e.g. [1]): Old status quo - foreign element - chaos - transforming idea - practice - New status quo... with the intent of using your present discomfort to evaluate changes you might want or need to make. If the idea seems helpful, have a look.
[0] 'More Secrets of Consulting: The Consultant's Toolkit', Gerald Weinberg
Typescript has allowed me to write JavaScript applications focused upon data structures without sacrificing expressiveness or usability. I am currently writing an OS and file system sharing application that executes in the browser with a full GUI.
I had to discover this on my own though. If I were waiting on the corporate world to show me fun and ambitious things I would have long since given up programming in its entirety. Constantly listening to people cry about how hard life is without megabytes of tools and frameworks to do their jobs for them and never having to write original logic, while enjoying all the amenities in the world, is really off putting.
It's possible that what you loved was not programming, but being a maker. As a professional programmer you're no longer a maker, the owner of the company is. You're executing his vision, not your own.
You'd probably enjoy building sand castles by the sea, but wouldn't like working as a construction worker building sky scrapers.
After 20 years of programming professionally, you may have found that a good few of the products you're making and tools you're using aren't ones you specifically enjoy. You may have found yourself at one or more jobs that weren't quite what you were looking for, and staying there mainly for the money, without feeling some of the intrinsic motivation you usually have.
If some of that applies to you, then perhaps the answer is that you should do programming that you enjoy. That could mean doing hobby projects on the side, it could mean trying to start your own business and seeing how that goes, or switching jobs and hoping you get lucky. If programming for 20 years has made you rich, then you could also try living off your savings (and the interest/dividends of what money you invest) and doing some of the above without a 9-5 and seeing how that goes.
Programming is in itself interesting and fun to me at times, but IME, don't count on it. Maybe it's fun for brief times while you learn a new language, technology or technique, but at all other times it's the problems you're solving that have to be fun and interesting, and programming is only part of the means to achieve the solutions.
Most fun job I've had constantly required me to learn to acquire new problem domain knowledge. Most boring job I've involved technology that was interesting to learn but rather mundane problems to solve and only really stayed somewhat interesting because of boredom driven architectural choices that introduced new technology to the projects to solve the same old problems.
And it's OK if a job isn't super fun for as long as you find something to do in your own time that's stimulating and interesting.
On a last resort there is an extreme solution that seems to work in any field especially artistic ones: stop doing it professionally. Get back to it as a hobby, exploring and playing with anything on personal projects without any financial pressure, and I'm sure you'll find that joy again.
It helps to do things you love, even if it’s not programming.
A little trial and error aids in discovery.
Initially you won’t know what it is you want to do but you’ll have some sort of curiosity about a project.
You can follow the trail and see where it leads.
Most trails are only five centimeters long. But don’t be discouraged.
When one thread disappears, another often takes its place.
Do this for long enough, protect that sacred time, and you’ll discover some passion.
I don’t doubt programming will find a way to re-emerge again in your life some day (in a pleasant, not tedious way). It encompasses so many fields.
You’ll sort of know when you’re on the right track, because what you love will be oddly peculiar and unlike many other people’s interests. You’ll have trouble explaining why you like doing it (as if it needed justification).
True interests (when properly followed) always looks a little crazy to outsiders.
I did. To me programming is like reading a book because you want it to (your choice of genre, no point except to read it and enjoy) vs reading a book because it is in your syllabus and you're gonna be graded on it at the end.
I think work related programming is the second kind (even if you're working for yourself) and working on projects which you make only for yourself is the first kind.
For me the trick is to not have any expectations (including any secret ones like getting github stars, upvotes, money or any deadlines). Also one thing that took the joy away before was not really programming related (which was always enjoyable) but the regret I felt sinking my time into it not doing anything"productive". Once I let go of the feeling it started becoming fun again.
Effectively programming is like writing or maths - as such it is intrinsically not that interesting to most people, but what you can do with it is.
I.e. most people find books more exciting than grammar, and specific application of math more interesting than just doing calculus disconnected from any practical problem.
While getting started with programming is more difficult than acquiring basic literacy, once you have it, it's not that big of a deal and to grow you need to move onwards (i.e. apply it to real problems or continue studying the theory).
Once you've mastered a certain level of basics, just learning a new language or API is quite pointless unless there is some value proposition tied to it.
I'm 16 years into my career. I still like programming but I wouldn't say that I love it like I used to. At the beginning I would discover and learn new things on a daily basis but now, after 16 years, it's usually more of the same and this is what killed the love for programming for me. I have become a mercenary. And that's ok, because I have a family and more important things than coding for fun.
But every now and then I discover something new and this is when I get excited again. This is what keep the little coder flame burning that is still left within me.
So I try to find something new every month or two that get's me excited again. Doesn't take much time and is very rewarding.
My theory I'm testing out right now is that if you end up doing other things that are valuable for a programmer to do, that isn't directly pr ogramming, you can still get paid and also foster other interests while your enjoyment of programming might recharge.
I mentor people, I architect and manage projects. I lean on communication skills and relationships so that the answer is easy and simple rather than complicated. I do code sometimes, but not the super heavy lifting. It may not work out great in the long term and I might have to take a break, or it might turn out that what I'm doing isn't as valuable somehow, but its working alright thus far.
I have ups and downs, I really enjoy programming when I can get my teeth into something I'm really passionate about, but there are other parts of the year where I fall into a "programmers block" and can't bring myself to do anything.
My fondest programming memories are those aforementioned passion projects, but they're often fleeting. What tends to happen is I go all in on something, write a blog post about it then it kind of drifts away and ultimately I drift too.
It's hard, I'm not sure how to solve it other than saying these feelings come and go - you'll find something/inspiration in the most unexpected places.
I'm in the latter right now, and am anticipating losing my job over it. I'm just not that motivated by doing somewhat arbitrary programming tasks, and at a certain point, the thing that was previously novel starts being insurmountably boring.
I'm still a student, so I didn't went throug the process of not enjoing programming and then rediscover that joy again. But have you tried working on a side project? I think that working on something you choose to do and without the anxiety of deadlines is one of the best ways to enjoy what you're doing. If you also wish to be helpful, there's lots of open source projects that would benefit from the contribution of an experienced programmer, maybe even something that you're already using daily so that by working on it your contribute is both helpful to yourself and others.
For myself the word that summarizes the best advice here so far is "introspection." A lot of people have mentioned burnout, work/play balance, languages, complexity of modern frameworks, and more. I think it's all constructive, but needs to be interpreted in a personal context.
When I was a kid programming promised to allow me to make incredible things. It was harder than it looked. I mostly abandoned it as a teenager, and then took it up again in college for the same reason. I've been doing it professionally ever since, for over 15 years.
Personally, the joy of any given task is mostly commensurate with how much effort and frustration is directed at the goal, rather than the technology that is supposed to help me get there. This is a big problem with software, because the medium is so complex, but it applies more generally. If I'm making something in the wood shop, it's one thing to be frustrated because I split the end of a board. It's much more deflating to find out that the power saw is broken.
It's partly practical: if I'm in a wood shop, I have the means to deal with a split board. I often do not have the means or the knowledge to fix the power saw. But just as importantly, it's about my own attitude. What would my 12 year old self do? My only choice was to grab the rusty hand saw, make a wobbly cut, and get on with it. Now that I'm older (I can drive and I have money) I'm more at risk of stopping everything to fix the power tools in the name of quality.
I'm currently working on contract and it has felt like an uphill battle. On reflection, I see that only a small fraction of my time is spent making the software that I was hired to build. The rest goes into fighting with the stack and the business side of the job.
The hobby project that I have on the back burner is a single page of javascript (which I am learning) with a horrendous 500 line function that draws stuff. It pays no regard to web development best practices. These are intentional constraints that limit what the output can be for the sake of my enjoyment. It's a ragged, broken mess, but it holds my interest. If I can just get it working, my friends will appreciate it! That for me is the childlike spirit.
I've been developing software for over 40 years now (35 years professionally) and I still love the idea that I can create something from nothing. I always have a couple hobby projects that I can spend a few minutes on ... things that stretch my skills or that involve a subject of interest outside my day job. I also make the software I write for work more fun by treating it link a craft ... if you see art in what you're doing, even mundane programming can be fun. Curiously, altering software to make it testable and writing the tests is one of my soft spots.
- fear free: I worked a min wage gig and coded on the side
- due to the previous I could extend my code by small chunks, pleasure often comes from small and regular victories
- work for somebody else (makes you less tempted to postpone stuff)
ps: I repeat this often because it's one of the rare time I found balance, progress, real output
pps: also question your motives, if they're subconsciously neurotic (some deep fear or anxiety) it will lead to parasitic short term actions rather than fulfilling mid-term experiences
1. Stop programming when you don't feel like you want too. Forcing yourself to do anything turns it into a chore. Let yourself relax
2. Stop programming what you don't like. If you hate java, stop programming in Java.
[Note, I realize the above two are difficult if you have a demanding job. I hope you really consider it though in any case, because long term it will help you]
3. Try building small things that you're actually interested in, in languages you love -- i.e playing in lisp or python, on a problem you're curious about, for a short time, can be very fun.
I get dips in my joy of programming when I'm working on mostly easy problems. This happened to me at a few places I've worked, the work becomes so easy that I can do it without thinking and there aren't a lot of areas to improve or so much red tape it isn't worth it. Recently I started working at a startup where I get to do a bunch of different types of task and everyday I'm learning new stuff. It made my joy of programming return and I realized that the joy comes from the challenge of it, for me at least.
I would start by taking a look at this article; it helped me understand what it is that I personally get out of programming: https://josephg.com/blog/3-tribes/
But I would also say, I don't think there's anything wrong with not enjoying it any more. Few people can do something for decades and still take joy in it. It's great if you can rekindle the fire, but it's also okay if your interests drift elsewhere.
Learn functional programming or different programming paradigms. For example learning Elm brought me a lot of joy and wanted to implement stuff like tetris, snake, other little apps and toys.
I'm halfway through rediscovering the joy of programming by only coding stuff that I'm actually interested in.
That is one of the main reasons I moved into a devops engineer role at a company that doesn't quite understand that devops is not a role, so while frustrating at times, it's actually quite handy, no more developing on a daily basis on stuff I'm barely interested in.
So far I've done a bit of developing at work for things that I've volunteered and doing some embedded programming in C because why not?
People who turn a passion into a side hustle often report losing their passion, so I can only imagine what turning a love into a 20 year career would feel like. The hedonic treadmill that is life cannot be defeated, but it can be out gamed by changing things up—completely. Change careers, go into a new area, take a long break so dopamine hits will actually land again, or just reconcile yourself to that part of your life having passed and find a new love.
My two cents: change career and move to another place. I moved every four years, from countries to countries, continent to continent, never worked more than 3-4 years in one job. Career change can be from your current employer to another one or from your current favorite language to something different. It is a radical mindset change, being a slow moving individual. but the wealth of learning from different places and cultures is fantastic.
There are pros and cons to this lifestyle. I quite agree that experiencing different cultures is fantastic and will radically change a person for the better. However, I've moved around quite a bit, different countries, different US states, different companies and IMO it gets extremely exhausting after awhile (judging by the OP's question, we are probably about the same age). Not to mention, having your friends and family in all parts of the world is tough. Throw in a partner (and even kids) and the only thing you start to desire is stability.
Plus, changing jobs every few years means that you are constantly in interview churn mode and as you age, you have less and less desire to deal with the moronic ways in which interviewing is conducted. Personally, I still enjoy programming and would still write programs even if I hit the jackpot in the lottery, but the way the industry behaves these days is a big part of why people get burned out.
This may work if you are single.With family and kids its hardship. I did this with my family ,now after 3 years i wanna move out but the kids find it difficult and my wife has her difference after kids.
My new paradigm is to talk about what I've done, not what I'm doing. I noticed a trend that I'd talk about things, and people would start chiming in with the own ideas before I was done. I was only sharing because I was excited about something, and for whatever reason, sharing with other people before it was ready made things less fun for me. So now I build for myself, and I work on whatever I damn well please.
Not sure if it will work for you but for me the joy in programming now lies in it helping me in my other hobbies.
I'm not following mail.python or any dedicated python-related blogs in the same way or with the same passion I was doing 10 or 15 years ago, but I still do enjoy using Python daily (and some JS) for implementing some of my hobbies (many of them relying on collecting, manipulating and presenting data).
20 years of anything is enough to evaluate other options. That's perfectly normal and expected. Congratulations on reaching this milestone! While you no longer find joy in programming, aren't the broader goals of why you're programming clear? Working without a sense of mission or purpose is a sure way to hate what one is doing. Are you getting that at your job?
Do you have any project ideas for Agda? I used it to formalize the simply typed lambda calculus; what else should I do? After all, I can't really do "traditional" programming projects in Agda as its ecosystem is more geared towards proving. Are there any interesting projects with proofs as a focus?
In fact I would be very happy to find a collaborator for those projects. There is lot of people from academia focused on the fundamental projects, but I am more focused in programming something practical.
Wow, cool! I'm still wrapping my head around Cubical Type Theory, so I'm not sure if I can help. I don't have the mathematical background to know what Matroids are (skimming the Wikipedia page, I see some set-theory-centric definitions that talk about subsets and powersets, to what extent would they translate to type theory?).
There is nothing special about them.
I am talking about simple formalisation, there is already some code about finite types in cubical-agda library, so it would be good place to start.
I think that usefull definitions and properties can be formalised in ~100h.
Matroids are known to be good example of cryptomorphic structures, so cubical agda can be used so that those cryptohmorphism can work "under the hood". I know how to do this, but I am currently working on something different.
If You are interested pm me.
Honestly, I quit my job a while ago and after a month or two was drawn back to projects I'd put off for years. I'm going to start a new job in a few months (UK civil service paperwork is slooow) but I've rediscovered the joy of doing my own thing. Being free from the constraints of other people's demands helped me a lot. I had no desire at all to code after work when work was half legacy projects and half managing people's egos. Now I'm reskilling in a hobby context and it's great fun. I might get a side income stream from it too.
TL;DR take a sabbatical if you can afford one, and don't go back to coding until you actually want to
For me it is either math + algorithmic challenges, like projecteuler [1] (which is amazing), or going back to system programming, like trying to write something worthy without libc. Like others have commented, I do need to do this every now and then (~once a year)
The thing that drained the enjoyment out of it (and to be honest a lot of life in general) for me was being stressed at work.
When I left my full-time job (where I worked way too hard) to do consultancy I started to de-compress and it helped me enjoy life a lot more. If I won the lottery I would still be quite capable of not touching a computer for 6 months though.
I became a teacher, so now I get to share the joy of programming with kids. I also manage the technology at my school, so I do some programming to enable that, which is enjoyable because I am pretty independent. I work at a great school with good kids, so my gig is not a common one, but it works for me.
That would be a big step down in terms of income isn’t it? I love teaching and have been tutoring my 6 year old and it’s fun but I don’t see many parents looking too eager to get their children learn programming.
The thing I love the most about programming is that it cannot be boring (at least in principle). If it is becoming boring (usually due to grind), there usually is some meta-process that you think of automating, and by devising how to automate the grind, it ceases to be boring.
Does anyone have any tips for the "micro" lulls? I'm a professional programmer of 5 years. Back in December I was floating high, feeling so empowered and at the top of my powers. Now I feel just meh. Opening an IDE, writing tests, etc, all feel like a drag.
You could rediscover programming with kids. Likely there is a local codo dojo or the like. When you have to dig down the lower layers of your programming skills to explain the most basic things in a fun way, you might remember why it was fun to you as well once.
Code something like you did in your teens. Or pick a very small personal project where you can code each feature in an hour or less. I recently started doing an asteroids clone in C and SDL and it is super fun, and it gives me more energy for my daily job.
I would argue most programmers can do that, if the desire is strong enough. You might have to lower your standard of living drastically, but it's possible for most of us.
Maybe change discipline. For me, I regained my joy when I moved away from back-end to front-end. For years I dreaded front-end development; now I'm fully immersed in it and never been happier. Of course this is different person to person.
Nothing wrong in changing your career up slightly. There are many other areas in tech that would greatly benefit from your experience without full on direct coding. Solution architect, management, devops, etc, etc.
Do you have any side projects that you do for fun? I find working on things that solve problems for me or that scratch an itch help keep me motivated even when I screw up on the simplest programming tasks.
I do not have any joy as most of the things are done in job - I did something not in the job like fpga. Or go back to emulate mainframe and run my old 370/xa but not ESA assembler etc.
I play a game called human resource machine. You succeed by implementing algorithms and then try to optimise them for space and time. It reminds me of what I like about programming.
When I discovered programming in my teens it was the single greatest thing I could do. I spent all my time doing it, constantly learning new things, breaking into new areas of discovery and then finding still more interesting thing. I wrote code for entertainment, I wrote code to relax, and sometimes people even paid me to write code.
Fast forward 20 years and I felt like it hurt to write code. So many things were in your way between the writing and the running, useless hoops to jump through, arbitrary changes to things that used to work just fine and now worked in a different way, why? why? WHY? I was pretty burnt out about it.
That lasted for a few years (okay probably closer to six or seven years) when I got a chance to help a teen learn to program who was super excited about it. I showed them the opaque APIs and they were thrilled, I showed them the crappy IDEs that prevented you from seeing what was really going on and they loved it, I showed them tool kits that created guard rails around what you could and could not code and that was just fine. They wrote line after line of code and marveled at each new thing.
It struck me that they were me and I was them and why were they so excited about this when I was so offended? After a lot of introspection I came to realize that the answer for me was that nothing had changed.
The reality I was missing was that computers haven't changed a whole lot since the IBM 360. The only thing that changed is that they got faster, smaller, and way cheaper. But their nature hasn't changed at all. They have registers, they have machine code, they have fast I/O devices and slow I/O devices, they have memory and displays and peripherals of various kinds. But at the end of the day, and this is especially obvious with various recreations and emulators, the computers of today are not really all that different in nature from the ones I learned programming on.
That in itself might not have been a killer, but the killer was software was by and large unchanged as well. After 20 years of programming, every single programming task felt like a remake of something I had already done. And for what? To implement it in the language of the day? Because you couldn't get the source to one version so you rewrite it from scratch to get better licensing terms? Lots and lots of software was done in the sense that there really isn't a good reason to re-design it, but there are a zillion reasons while you might be asked to re-write it.
Imagine if you were a screenwriter or a songwriter and someone said, "Ok we need 'Gone with the Wind' but now its going to have a gay couple, take place during the Syrian Civil war. Don't change any part of the plot or the story or the relationships, just swap Arabs for Southerners, Syria for the South, and have the love interest die of MERS or something."
Wouldn't that be a crappy job? What can you do with that? Where is the creativity? Where is the opportunity to express a fundamental truth in a new way?
I realized that I had come to hate programming because everyone was asking me to program the same stuff that had been written before but now in the Fluff Framework. I could do that with my eyes closed and so could any teen fresh out of college. What did they care that it had been implemented twice, three times, maybe five times previously in different ways?
Once I understood my problem I could start working on the solution. I decided to start writing software in areas where I had never written code before (like DevOps), or in areas where hardly anybody had re-written code before (like software radios). I also started to meticulously develop a workflow that ran on every operating system I might have to work on (Linux, Windows, and MacOS) that worked for me and saved me from having to relearn a new thing "just because" someone got it in their head that they could "improve" text editing for coders. When the friction between thoughts and code and execution are low, and the problems being coded or solved are novel, I love programming. Because I know what to avoid (arbitrarily complex tools and rewriting CRUD code again and again) my level of joy has gone up significantly.
I don't know if any of this will resonate with your question but it worked for me.
Try side projects. Could be something you're been thinking of trying out (scratching an itch), or to learn something new.
For example, recently I made a macOS Quicklook plugin for displaying the Basic listing for program files for the first 8-bit computer I learned to code on (https://github.com/sebastienboisvert/ZX81QuickLook).
The first one was a lot of fun for me, as it got me back to my 'roots' (re-acquainting myself with Z80 assembly, besides the nostalgia aspects), and along the way I learned some of the newer features of CSS and JavaScript (it had been so long since I worked in JS that I didn't know it had async functions now!). The second one is out of my 'comfort zone', and is forcing me to learn some new unfamiliar frameworks that need to replace the old code.
Initially, I wanted to only allow myself to start on them once I had completed doing a lot of other things that needed to get done (being such a procrastinator) - but I found that just doing them without those restrictions relaxed me more, and allowed me to get those things done more easily anyways (it served as a diversion, but a good one that I didn't need to feel guilty about).
If you're coding day-in day-out, doing the same routine, think about 'tuning out' at night - leave the computer off, and do something else altogether; take up a new hobby, or read some books, or anything that interests you. The point is to change the scenery a bit to recharge.
If it's available to you, you might consider taking on (or asking for/seeking) something that's new to you at work, that opens up new opportunities, both for learning and potential advancement. Any good employer should recognize and appreciate that.
As others have noted, 20 years is fairly long time, especially if you've only done the same general thing; as such, it might also be worth considering a bigger change. Maybe it's time to take on something else that's more challenging, that can help you grow. That could be something along the tracks of a more managerial nature (or simply taking on more of a leadership role, if that sound too scary), or perhaps something in an entirely new direction.
There's a lot of good feedback here - soak it in, think about it, and consider what might help you get that excitement back. Making changes doesn't mean you give up what you love doing - it might be simply the thing you need to rekindle your interest in it.
You assume "burnout", which s/he didn't specifically state.
S/He asked "Have you rediscovered the joy of programming". Doesn't mean necessarily less programming - might mean more programming of the type s/he got joy out of.
I wasn't 20 years into my career when I did this (more like 10), but at one point I had a serious "lapse of faith" with regard to my career. I was working for a terrible company with an even worse manager and I was miserable. I didn't know if I wanted to be a programmer any more. I quit my job and didn't look for another one.
Instead, I wrote free software -- initially just for a month. I got up in the morning, had a shower and worked on whatever project seemed interesting to me at the time (which was actually the GNOME Corba ORB -- that's how long ago this was ;-) ). At first I was pretty unproductive (and I'm not sure I ever actually made a contribution... can't even remember). I watched the stock market go up and down on the TV and occasionally turned the channel for more educational content (I invented the "Teletubbies Drinking Game" -- Drink whenever they say "eh oh" and drink twice whenever they say "again!"... which is to say that I don't think I ever lasted an episode).
Anyway, one day I was having a shower and I had an idea about programming (I can't remember what it was). I ran out of the shower and started typing away. Every day after that I had a similar experience. It took me a week before I realised that I was so preoccupied that I often wasn't wearing any clothes. (Actual awkward conversation: I was chatting with a woman who was moving out of the apartment. She recognised me: "Oh you are that nice man who programs by the window every day. Such a shame I will miss that from now on"...)
After about 6 months of doing this, I realised that I loved programming. I hated my job. The hatred of my job so overwhelmed my natural love of programming that I got to hate it too. But, like a starving man, as soon as I had the time to get back to my passion, I was ravenous. After that, I was much more careful to take jobs that I liked. I often worked for incredibly low salaries just because I liked the people or I liked the project. I was also careful to save enough money so that I could always take a "sabbatical" -- just quit my job and spend half a year writing code that I wanted. I was single (despite/because of my proclivity for exhibitionist programming), so it was easier, but I think it can be made to work in a family setting too.
I think the best thing I can say is that when taking a job, it's important to find a win-win situation. I find that when I get in trouble it's because I end up doing things that I think are important for the company, but which I don't want to do. Often these are things that my management don't want me to do either, which leads to a bad relationship with the management. I usually think, "Oh this is crap! They are totally dropping this stuff on the floor. Someone has to clean up this mess" and then get trapped into doing lots of stuff that saves the company, but destroys my soul (and somehow makes me an enemy of many of the people around me). So instead, I just try to do the things that both my management and I want me to do. Usually there is more than enough stuff that I want to do that we can find a mutually beneficial overlap.
The most important point: I let the company burn down around me as I play my fiddle. Um... Maybe not the most apt analogy. But I hope you get the point. I only do the non-fun parts of my job, if I really get the impression that somebody wants me to do it! That makes such a massive difference, it's incredible (although I often make the same mistakes of the past, but I try to correct it). When the company is intent on flying into a wall at 1000 miles an hour, I don't stop it. I just start looking for another job ;-)
OT, but as someone who worked on it, what in your opinion was the reason for the failure of ORBit and Bonobo? I very frequently find myself wishing we (as an industry) had stuck with CORBA and (D)COM, instead of finding ourselves now writing shitty 'microservices' with JSON serialization or ad hoc crappy binary protocols when we get 'fancy'.
So many things were developed in the late 1990's and early 2000's that indeed were hairy and tricky to use; and as a fresh developer I too hated much of it and tried to avoid them. So in that sense I was part of the problem. But now that I have some years of experience, I can't help but feel that we do so much things in ways that were solved 20 years ago, just because the newcomers in the field don't understand or can't be bothered to learn the history and why things are the way they are - and the whole 'simple framework of the months' cycle keeps going.
I guess this topic is relevant to the discussion after all - I think much (at least some) of our burnout is because of this never ending cycle of 'new' for the sake of new, yet seldom really better than what we had before. But maybe it's just rose colored glasses, and things now really are better...
I'm also programming since over 20 years. While there are times, tasks and aspect which I don't like too much, or which can be depressing, overall I still enjoy it.
But maybe let me add some random points:
- I do side projects from time to time. All of the open source on GitHub. Either in some new programming language which I want to learn about and just try out, or some preferred well-known programming language but a new fun (maybe challenging) task. Or maybe not challenging but actually easy but still fun, e.g. like writing a small game. There are many possible variations and options for side projects, and each case can be rewarding. As you start from scratch, you can try out whatever you want. If you set the scope small enough, you can soon get some nice results. Maybe really the most fun side project is to write some small game. Side projects is also one of the best ways to widen your scope to new areas. Maybe also the only option. In some cases (but this should not be the focus), you can integrate the side project back into your day-to-day work.
- Maybe the project you currently work is too big, buggy, unorganized, and annoying to work with. Take a step back and think about ways how to solve some of the annoyances. Maybe some subsystem can be rewritten. Maybe the startup time is too long and this can be solved somehow. Invest some work in making your workflow easier. Turnaround time for development is important. Maybe you can develop a testing environment where the turnaround time of development and testing can be much faster. There are many options here. Many of the will require some initial work but this can be greatly rewarding. In general, for me the most annoying thing is when something is slow. When I need to wait too long until I see the result of sth I just tried out. It could also help to get some better hardware.
- Other hobbies despite programming can be important too. Probably most relevant is some sort of sport, or any activity for the body. Hiking in the nature can be nice too. Take frequent off-times. Make this regularly such that it becomes a routine. E.g. I have a couple of sport courses, some in the mid of the day (so this is my extended lunch break), some in the evening. They force me to stop the work I'm doing right now. This is often a good thing because it forces you to take a step back and rethink about what you are working on right now, if you really tackle it from the right angle, or if you maybe should shift your priorities on other things. And also this gives you time in developing some new ideas, maybe about your work, or also new fun side projects, or new other unrelated hobbies.
- Socialize. Talk with other people. If you live alone, maybe change that. Talking can also be technical. I enjoy it, to get some new input, or talk about some new technical thing I read about, or maybe also something I don't know too much about. Talking can also be non-technical, about random stuff, about your hobbies, etc. If you are in a group with other shy people, just talk whatever is in your mind right now, even if the other people might not have a solution. Just talking about your programming problem, or whatever, helps.
For me, I needed to treat programming at work and programming at home as two different mental "things" that have zero correlaton. Programming is a skill like reading - you can do it at work and you can do it at home. Do people get burnt out from reading emails or whatever at work so much that they don't get enjoyment out of reading books or whatever in their own time? Perhaps, but it feels to me that reading is too much of a "core" or "fundamental" skill that you cannot allow your job to come to "dominate" or "own" that - it is a universal part of your life and education that it needs to exist separately from your day job - programming is the same.
Also I feel that there is a lot of pressure within communities like HN that implicitly (... or outright explicitly) makes you feel like you should always have a side project on the go, or you should be working on some amazing start-up idea, or you should be contributing to open source etc. All of that is basically a second job I'd say - you need to apply the same mental energy and rigor doing that sort of thing as you would in your job. I feel like this is an unhealthy mindset and unfair expectation.
I don't know about you but when I was a kid just starting out in programming I just messed about doing whatever I fancied without any expectations of "releasing" anything or turning a profit etc - I just scratched my own itch and left a chain of unfinished ideas and projects behind me as my mind wandered and I had zero mental attachment to any particular idea or objective. I was free to follow my own path without feeling that I needed to give an idea justice and see it through to some kind of release or public distribution etc.
I now personally try to do the same now too - I try to avoid letting any ideas about "releasing"/sharing/distributing any of my spare-time work from creeping into my mind. If I go into something knowing that I might close the IDE the same evening and never ever open the file again, or I can write hideous hacky messes because why the hell not, or I can just forgo any kind of tests or repeatable builds etc etc then that is freeing and removes a lot of the mental baggage of doing a "good job" and let's you concentrate on satisfying your own needs.
Oh and also unlike other people on here, I personally recommend JavaScript as a great language to use for personal messing about - flexible, universal, performant, and most importantly it has absolutely zero barrier to entry - you can litterly just open your browser's dev console right now and you are up and running, or just create a .HTML file and you are up and running that way too without any joy-/motivation-sapping bullshit or ceremony related to setting up build files/python anaconda bollocks/environment variables/installing compilers or other nonsense - it just works right now with what you already have on any computer you sit at (... or you can go deeper and install typescript compilers or node+npm etc if you want to) Ignore comments about churn or change-fatigue regarding JavaScript - the language itself is separate from the libraries people use and you can go a long way with the core language and modern standards-based APIs without ever touching an external library.
I deleted my rather cynical post, about how we can "age out" of frontline programming, and will replace it with this rather sunnier treatise:
Open source work.
I was a manager for over 25 years. I'm a really good manager. I could probably be an ideal CTO.
But I don't love it. I love writing code.
As my management track progressed, I found my technical work deprecating. It did teach me to be a lot more "strategic," and "architectural" in my approach, but I found that I was sitting down and banging out code less and less.
To make things worse, I kept reading about how the tools and techniques were progressing to levels far beyond what I had learned.
I didn't have a "shower clause" in my employment contract (where the employer insists that they own the ideas that you come up with in the shower before work), so I was free to write software in an extracurricular manner, as long as I didn't use employer time and/or resources to do so.
So I started to do open source. In the beginning (about 25 years ago), there wasn't a good infrastructure for shared configuration management, so most of the work I did was published "after the fact" (otherwise known as "deliverable"). I would make the source available, "on the side."
Nowadays, with things like GitHub, GitLab and BitBucket, you can actually run a distributed collaborative open-source (or closed-source) project, with the process open. It also works great for single-engineer projects.
The result, these days, is that I have a GIGANTIC portfolio. Hundreds of thousands of lines of crafted, artisanal, small-batch, single-source code, in dozens of repos. I like to use the MIT license for my work.
I tend to design architectures; not apps, and some of the designs I've done have lasted decades (although with many changes along the way).
I found a need in an underserved community, and designed an ecosystem to help them meet their needs. For free. It's now becoming the global standard (but for a small demographic).
If you can find a need that usually can't afford your level of skill, you can find a home. It can be quite challenging, but that which does not kill us makes us stronger. It taught me to plan for the future, and for limited resource pools and budgets. It taught me to support my work, and do work that can be supported and passed on to others.
Ironically, my open-source tech work informed my "day job," as well.
Open source work.
In the movie "The Graduate," the equivalent of the "OK Boomer" (in those days), lectures a young Dustin Hoffman with "One word: 'Plastics.'"
I manage to do it every so often, mostly because I stumble into a problem far outside my usual domain and I avtually feel technically and intellectually challenged again.
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 re- moved from pure thought-stuff. He builds his castles in the air, from air, creating by 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. (As we shall see later, this very tractability has its own problems.)