i would say "3. Working in real projects at industry" when i was 19 i had the opportunity to build real world systems. Durning that year i delivered a full stack e-commerce using MVC pattern for a client. Someone who is just starting its a lots of hard work to deliver a MVC full stack app and i learned a great deal.
Later i joined a USA based startup really large project. This is where i learned how to manage large SaaS apps and how to manage complexity.
Since then i have been only building SaaS products and i love it. Currently i am leading the development of microservices based system based on GraphQL and everything is running k8. i have worked on every part of that system.
1. In India, there are only ~100 jobs for a Clojure developer. That includes people just throwing in Clojure just to hire Java/Scala developer.
2. The learning curve for the Clojure. Clojure is simple but it's not easy by any means.
3. JVM interop if you are not a java developer it adds in more learning time. Most of the Clojure libraries use java heavily. It's a good thing but it adds in an extra layer of learning java's ecosystem.
4. Error messages. Even after years of Clojure. I still find it hard.
5. Documentation. Most of the packages I use don't have dedicated websites or good documentation.
Even after all the issues. It's still worth the investment. I started working on a crawler for a freelance gig. we first built it using Golang. But due to its complexity and lots of bugs due to mutation. We ported it to Clojure and we are not looking back.
I have a project that is going on since 2015. So ran the above command to see how much code we have. I was expecting our models to be really large turns out we have ~(404 * 3) rest endpoints. the scariest thing was Vendor dir.
Agree, Clojure has the most influence on me. There are lots of things to learn from Clojure and I don't see anyone taking lessons from Clojure people. it seems like everything is just one large MVC after rails. We are not ready to move on.
> I'm also afraid of digging an inescapable hole of untestable spaghetti code and tech debt.
if you are worried about tech debt you should watch "The art of destroying software". It will be hard to understand at first.
Here is TL;DR. Writing small services that will take only one week of work to rewrite. That way you can burn your services and recreate when you truly understand your domain.
Recently I worked on a REST API using go. I think the go package system has good support for writing small and independent packages. Just make sure your microservices are micro.
Later i joined a USA based startup really large project. This is where i learned how to manage large SaaS apps and how to manage complexity.
Since then i have been only building SaaS products and i love it. Currently i am leading the development of microservices based system based on GraphQL and everything is running k8. i have worked on every part of that system.
I think starting early helped me a lot :)