Ask HN: How to rediscover the joy of programming?
I remember in my teens I used to love programming. After 20 years of a career, I don't enjoy it anymore.
Have you rediscovered the joy of programming? Any advice?
Have you rediscovered the joy of programming? Any advice?
336 comments
[ 3.5 ms ] story [ 326 ms ] threadI 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.
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).
sbcl 1.4.16 uses single floats: https://ideone.com/ruw5qi
I don't know enough about Scheme to dig under the covers to see how it's being represented internally.
(setf read-default-float-format 'single-float) (+ 0.1 0.2) => 0.3
(setf read-default-float-format 'double-float) (+ 0.1 0.2) => 0.30000000000000004
On LispWorks 7.0 I get 0.30000000000000005 for double-float. Hmm.
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:
Aside from financial applications, there’s very little reason to care about the trailing remainder.
"Financial applications" happen to be pretty common reasons for number crunching :)
Internally, they're probably both 0.30000000000000004 (depending on precision), so an equality check returns true.
It could also be that they're both 3/10 rational numbers, but given other tests in this thread that's likely not the case out the box.
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)
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.
[0] - https://github.com/phoenixframework/phoenix_live_view
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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".
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.
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'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.
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.
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).
Everywhere somebody built an abstraction to do it.
#include <SDL.h>
...........
SDL_Init(SDL_INIT_VIDEO);
SDL_Window *window = SDL_CreateWindow("MyApp", 0, 0, 1920, 1080, 0);
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.
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.
Interestingly I believe the sendmail config file syntax is Turing complete. You could theoretically create a web app using SMTP as the backend API.
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...
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].
[0] https://learnxinyminutes.com/docs/prolog/ [1] https://www.metalevel.at/prolog [2] https://youtu.be/G_eYTctGZw8 [3] https://github.com/TheClause/learn-prolog/blob/master/articl...
[a] https://github.com/mthom/scryer-prolog [b] http://tau-prolog.org/ [c] https://github.com/preston/ruby-prolog
I.e. stop programming for the sake of programming. A new paradigm, language or methodology to be more efficient.
Instead solve problems, and use the tools at hand, my excitement from programming originally was the idea that I could build anything.
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?
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.
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.
http://www.paulgraham.com/hp.html
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.
Joy is out there, don't lose hope, and good luck!
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.
It's awesome!
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.
Side projects are always an option, I guess.
The problem is I don't have a good track record for completing projects so competitors or collaborators would be greatly appreciated
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.
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
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.
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.
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.
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 don't contribute any code, I just code review, do product planning, and conduct weekly sprints. We try to document a quick summary here: https://github.com/garageScript/c0d3-app/wiki/Sprint-H1-2020
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.
Highly suggested.
“Writing Rust code feels very wholesome”.
–John Carmack
I couldn’t have said it better.
1. First watch the SICP series (https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CAB...)
2. Then work through the book (https://mitpress.mit.edu/sites/default/files/sicp/full-text/...)
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 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.
* the concept of assignment implying _time_ and messing with the substitution model.
* recursive functions that are iterative
* iterative structures that are recursive
* At the base of the base of the data abstraction in LISP is, well, nothing.
* Code as data, data as code, really strongly underlined.
* The whole LISP written in itself (as a sort of fixed point of a language that defines a language). That is really something.
* The idea of using a language to write a language that lets you express your problem.
That last one is probably obvious to most, but it was really novel to me (despite years of writing functions to compute answers).
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.
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 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.
Time you enjoy wasting is not wasted. I often need to remind myself of that.
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.
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.
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.
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 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.
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.
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)
[1] https://en.wikipedia.org/wiki/Scale-free_network
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.
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.
I did not, in fact, say they were.
> 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.
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?
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.
Changing hobbies is not the same as trying to change what you did for a living for the past decade.
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.
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.
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 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.
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.
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.